JEP 132: More-prompt finalization

[Vitaly Davidovich]

Hi Tony,

One case I can see where doing a GC during low activity would help is so
that when activity resumes the GC spaces are as clean (and compacted, if
necessary) as can be and thus throughput and latency can be reduced when
activity resumes.  Presumably you'd run just one such GC per low activity
period.
On Jan 5, 2012 11:46 AM, "Tony Printezis" <tony.printezis at oracle.com> 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.
>
>  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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20120105/1334e3df/attachment.html