JEP 132: More-prompt finalization

[Tony Printezis]

Kirk,

On 01/05/2012 12:37 PM, Kirk Pepperdine wrote:
>> Well, having lots of memory can allow us to have lots of "room" in the heap to postpone GC. However, there are native resources that are reclaimed by finalization that are scarce (typically there's a fixed number of them, or limited amount of memory we can dedicate to them, etc.) so extra memory is just not going to help: there are likely to run out before the heap is full enough to cause a GC. Increasing their max number is a short-term fix and will only postpone the inevitable.
> Right, so you're relying on finalization when you should be using a normal close mechanism.

See below.

>
>>>   I dream about a time when JVM would be able to
>>> detect low load time and start GC/finalization automatically.
>> I can't see how this is going to help:
>>
>> - If you detect that the machine load is low it doesn't also mean that there are garbage objects in the heap that need to be reclaimed or finalized. So, triggering GC "opportunistically" will be, I'd guess, unproductive most of the time.
>>
>> - In fact, if the machine load is low it means that the application is not doing much, therefore maybe there are not many objects to be reclaimed / finalized. Which means that this is probably the worst time to trigger GC.
>>
>> - It's not always desirable to do work that might be unproductive when the machine load is low. Consider battery powered mobile devices: doing potentially unproductive work could drain battery unnecessarily.
> Right, this assumes that the app is creating objects when it's busy. We both know that this isn't necessarily true in the low-latency case.

Sure, but that's the exception. I'd bet that the above is true 95+% of 
the time.

>   That said, triggering a GC when the machine appears to be idle in a low latency application is unlikely to do much more than burn CPU cycles (and battery).

Bingo.

>>>    But today there are a cu's cases that can't be solved without such API.
>> I agree with you that giving users an API to trigger GCs / finalization is not optimal given that they will most likely mis-use it (and they do). However, giving an API to library writers to inform the GC how much of a native resource is currently being consumed (say: 43 files are open out of a max of 100) and let the GC decide what to do is probably a better approach (IMHO).
> I get the feeling that what people are looking for is a destructor.. and in Java the destructor is close().

....inside a finally { } clause. :-)

> One has to consider finalization of any resource to be the mechanism of last resort or when all else fails, finalization will catch it (assuming it has a chance to run). Eg, it's the application's responsibility to call close().

I agree. And I'm sure I can dig up some of my slides from past talks 
that make this exact point: if you know you're done with an object, 
please call close() on it. However, as it's already been pointed out in 
an earlier reply to this thread, it's not always possible to rely on 
close(): reclaiming DirectByteBuffers that are not guaranteed to be 
unreachable could be a security issue.

Tony

> If you know enough to call System.gc() (or any other API), you should know enough to call close.
>
> Regards,
> Kirk
>