Free ratio based heap shrinking in the parallel collector

[Hiroshi Yamauchi]

On Fri, Mar 26, 2010 at 4:59 PM, Jon Masamitsu <Jon.Masamitsu at sun.com>wrote:

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

I think we agree that it's a good idea to try to shrink the heap in response
to System.gc() in such a scenario/app.

Since we are talking about a setting where the free ratio flags takes
precedence over the psAdaptiveSizePolicy's throughput goals, the suggested
logic in the original webrev is perhaps not so terrible? If so, I suppose
the logic for UseFreeRatioOnlyInSystemGCForParallelGC does help with that
because it can shrink the heap regardless of the throughput goal. It may
make sense to remove UseFreeRatioForParallelGC and keep
UseFreeRatioOnlyInSystemGCForParallelGC only. If you'd like to see it happen
inside psAdaptiveSizePolicy instead, the current webrev does not work.

Thanks.

Hiroshi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20100331/7ead0c14/attachment.htm>