JEP 132: More-prompt finalization

[Tony Printezis]

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.

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

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

Tony