JEP 132: More-prompt finalization

[Kirk Pepperdine]

On 2012-01-05, at 5:45 PM, Tony Printezis wrote:

> Dmitry,
> 
> On 12/28/2011 12:44 PM, Dmitry Samersoff wrote:
>>>> Each of them has it's own workaround (e.g. connection pool manager with refcounting or separate checker thread)
>>> I'm not sure that I'd call these work-arounds as they all serve a multitude of purposes.. but, beyond the scope
>> Nowdays we have plenty of memory so we can delay socket (an other
>> resources) reclamation but save some CPU power.
> 
> 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.
> 
>> It's especially valuable
>> if an application have clear visible pick and spare hours.
> 
>>  I agree with you - there is no reason to have an API to trigger GC or
>> finalization explicitly.
> 
> I totally agree with this ....but also 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. 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).

> 
>>   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(). 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(). If you know enough to call System.gc() (or any other API), you should know enough to call close.

Regards,
Kirk