JEP 132: More-prompt finalization

[Tony Printezis]

Vitaly,

Sure, but if the GC detects that the load is low it doesn't know whether 
the load will remain low for 5 ms or 5 hours (and it's impossible to 
know, maybe not even the application knows). I can already imagine the 
bug reports: a spike suddenly happened in the market and the JVM was 
"locked up" for several seconds!!!

Tony

On 01/05/2012 12:48 PM, Vitaly Davidovich wrote:
>
> 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 
> <mailto: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/20120106/a43c670e/attachment.html