Free ratio based heap shrinking in the parallel collector

Jon Masamitsu Jon.Masamitsu at Sun.COM
Fri Mar 26 23:59:39 UTC 2010


On Mar 24, 2010, at 5:01 PM, Hiroshi Yamauchi wrote:

> Hi Jon,
>
> You're right that adjust_for_throughput() will not shrink the heap.
> Another part of the policy is that the heap is shrunk if the
> throughput goal and the pause time goal are being
> met.   It's a slower process than just enforcing MaxHeapFreeRatio
> and requires a number of GC's (that is, the heap would be
> shrunk down a percentage at each GC).
>
> GC usually happens only as needed. So, after the application goes  
> idle, GC does not probably happen. The next GC happens only after  
> the application goes active again. Assuming that, there aren't many  
> chances to shrink the heap (maybe only one). If the application  
> calls System.gc() right before going idle, that may be the only  
> chance. In such cases, the slower process may not work very well.

Agreed.  The option to use MaxHeapFreeRatio/MinHeapFreeRation on a
System.gc() is needed.  As you say we probably only get the System.gc()
to do anything.

>
> We would
> need to change the UseAdaptiveSizePolicy to do something like
>
>
> if ( average-pause > pause-goal)
>          shrink heap
> else if (average-throughput < throughput-goal) &&
>            ! (UseFreeRatioForParallelGC && heap too empty))  <<<< new
>         grow heap
> else
>         shrink heap
>
>
> Or maybe something like
>
>
> if ( average-pause > pause-goal)
>          shrink heap
> else if (average-throughput < throughput-goal)
>          if  (UseFreeRatioForParallelGC && heap too empty)    <<<< new
>                 shrink heap (policy-to-be-determined)         <<<<
>          else                                                 <<<<
>                 grow heap
> else if (average-throughput < throughput-goal)
>         grow heap to reduce gc overhead
> else
>         shrink heap
>
>
> OK. I think the latter may be able to shrink the heap more  
> aggressively.
>
> Do you think the free ratio-based shrinking should happen only when  
> the throughput goal is met? Using the above scenario, when the  
> application is working hard (and perhaps GC is working hard as well)  
> and goes idle next moment, the average throughput at the time of the  
> phase change may not be good enough for the goal to be met (hence no  
> shrinking).


I don't believe we can handle that case (application suddenly going  
idle and GC does
the right thing).   As you say earlier we might not even have a GC.    
And whose to know
if the going idle isn't to be followed almost immediately by furious  
activity again.  The application has to
make that call.   What we add here is the requirement to limit the  
amount of free space in
the heap even if the throughput goal is not being met.

>
> Thanks,
> Hiroshi
>




More information about the hotspot-gc-dev mailing list