Free ratio based heap shrinking in the parallel collector

Hiroshi Yamauchi yamauchi at google.com
Thu Mar 25 00:01:30 UTC 2010


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.


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

Thanks,
Hiroshi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20100324/72d17dc0/attachment.htm>


More information about the hotspot-gc-dev mailing list