JEP 132: More-prompt finalization

[Srinivas Ramakrishna]

On Sun, Jan 8, 2012 at 11:44 PM, David Holmes <david.holmes at oracle.com>wrote:

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

I don't think the overhead would be high. The tracking we are considering
is of a very simple nature, with the libraries doing
some (atomic) incrementing and decrementing of a counter per allocation or
finalization respectively (we could avoid
contention by deferring updates to a global counter except at specific
points although that may make rate calculations noisy),
and GC polling using these  counters to decide if a GC cycle should be run
because the resource may be close to exhaustion
in a little while. (One could alternatively have the allocation itself
detecting that fact and nudging the GC subsystem to check;
one can engineer this in a manner such that the cost itself can be made
fairly small.)

I suspect that the inline cost of these actions on native resource
allocation will likely be quite small, even if not
negligible, compared with the total cost of such a native resource
allocation, i am guessing.


> If the proposal involves new wrapper classes that an application has to
> opt-in to use then that is fine.
>

Certainly, any such API should allow for opt-in (perhaps on a
per-native-resource basis), albeit likely on a JVM-wide basis (per-resource)
 to make the resource-tracking effective.


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

Certainly that is the first step and who knows, it may allow us to mostly
kick the can further down the road for a bit longer.


> Although we "all" know "finalizers are evil", they exist and are
> (mis-)used by some apps and cause some issues.
>

Fully agree.
-- ramki


>
> Cheers,
> David
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20120113/3054bcbf/attachment-0001.html