Free ratio based heap shrinking in the parallel collector

Jon Masamitsu jon.masamitsu at oracle.com
Mon May 3 17:55:56 UTC 2010


Hiroshi,

In parallelScavengeHeap.cpp

In the UseParallelGC collector the initial size (init_size) can be
significantly larger than the minimum size.   If you want to shrink down
the heap to minimize footprint, do you really want to limit by the
initial size instead of the minimum size?

1001     maximum_desired_capacity = MAX2(maximum_desired_capacity, init_size);

Similarly here the amount of used data could be very small and
setting the floor at the initial size may not be what you
want.

1034     minimum_desired_capacity = MAX2(minimum_desired_capacity, init_size);

In psYoungGen.cpp you guard output with PrintGC only.  In similar
cases this type of output is guarded with Verbose also.  Does this
output as is get printed in the middle of the usual
-verbosegc (also known as PrintGC) line?

1000   if (PrintGC) {
1001     gclog_or_tty->print_cr(" Resizing young gen. expand_bytes=%d,%d",
1002                            eden_expand_bytes, survivor_expand_bytes);
1003     gclog_or_tty->print("BEFORE: Young Gen: ");
1004     gclog_or_tty->print("eden capacity : " SIZE_FORMAT ", ",
1005                         eden_space()->capacity_in_bytes());
1006     gclog_or_tty->print("eden used : " SIZE_FORMAT ", " ,
1007                         eden_space()->used_in_bytes());
1008     gclog_or_tty->print("survivor capacity : " SIZE_FORMAT ", ",
1009                         from_space()->capacity_in_bytes());
1010     gclog_or_tty->print_cr("survivor used : " SIZE_FORMAT ", " ,
1011                            from_space()->used_in_bytes());
1012   }


In psOldGen.cpp you could try to expand up to max_gen_size
instead of returning?

  501 void PSOldGen::try_to_expand_by(size_t expand_bytes) {
  502   if (expand_bytes<  MinHeapDeltaBytes ||
  503       capacity_in_bytes() + expand_bytes>  max_gen_size()) {
  504     return;

Additionally PSOldGen::expand() chooses to use MinHeapDeltaBytes
as the minimum expansion size (in the sense that sizes for expansion
are round up to MinHeapDeltaBytes).   You would rather not expand
for less than MinHeapDeltaBytes?   I'll admit that there maybe some
inconsistencies in the way MinHeapDeltaBytes is used.  Just checking
that this is what you want to do.

Again, seems to me that you want to shrink down to the minimum
generation size as opposed to the initial size.

  523 void PSOldGen::try_to_shrink_by(size_t shrink_bytes) {
  524   if (shrink_bytes < MinHeapDeltaBytes ||
  525       capacity_in_bytes() - shrink_bytes < init_gen_size()) {
  526     return;
  527   }

In globals.hpp.  We may want this feature implemented in other
collectors at some point - G1 comes to mind.  I'd drop the leading
PS on the flag so that it is ResizeByFreeRatioWithSystemGC.

3079   product(bool, PSResizeByFreeRatioWithSystemGC, 
false,                     \
3080           "Resize the heap by free ratio in System.gc() 
"                   \
3081           "under UseParallelGC")


The rest looks fine.

Jon

On 4/29/10 2:48 PM, Hiroshi Yamauchi wrote:
> OK. No problem.
>
> On Thu, Apr 29, 2010 at 1:58 PM, Jon Masamitsu<jon.masamitsu at oracle.com>  wrote:
>    
>> Hiroshi,
>>
>> These changes are what I was expecting after
>> we had talked.  I still have to look at the details but may not
>> get to those for a couple of days.
>>
>> Jon
>>
>> On 04/28/10 13:37, Hiroshi Yamauchi wrote:
>>      
>>> Jon,
>>>
>>> Here's an update based on what we discussed:
>>>
>>>   http://cr.openjdk.java.net/~rasbold/69XXXXX/webrev.02/
>>>
>>> The summary of the latest changes is that
>>>
>>> 1. On minor collections, the free ratio is computed based on the young
>>> gen heap, rather than both the young gen and the old gen heaps.
>>>
>>> 2. When -XX:-UseAdaptiveSizePolicy, the free ratio based resizing
>>> happens on normal collections, rather than just on System.gc() when
>>> -XX:+PSResizeByFreeRatioWithSystemGC.
>>>
>>> Hiroshi
>>>
>>>
>>> On Tue, Apr 13, 2010 at 11:21 AM, Hiroshi Yamauchi<yamauchi at google.com>
>>> wrote:
>>>
>>>        
>>>> Hi Jon,
>>>>
>>>> I finally got to this. Here's the webrev for a second version based on
>>>> our discussion (thanks to Chuck Rasbold):
>>>>
>>>>   http://cr.openjdk.java.net/~rasbold/69XXXXX/webrev.01/
>>>>
>>>> The summary of change is that the logic for expansion based on
>>>> MinHeapFreeRatio was added and only the flag for the System.gc was
>>>> retained (and renamed to PSResizeByFreeRatioWithSystemGC.)
>>>>
>>>> Thanks,
>>>> Hiroshi
>>>>
>>>>
>>>> On Thu, Apr 1, 2010 at 9:02 AM, Jon Masamitsu<jon.masamitsu at oracle.com>
>>>> wrote:
>>>>
>>>>          
>>>>> On 03/31/10 11:26, Hiroshi Yamauchi wrote:
>>>>>
>>>>>            
>>>>>> ...
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>>              
>>>>> Yes on the shrinking on a System.gc() and perhaps for symmetry also
>>>>> expanding
>>>>> a small heap to MinFreeHeapRatio?  UseAdaptiveSizePolicy will shrink the
>>>>> heap
>>>>> down during periods of low activity and it might be useful to swiftly
>>>>> expand
>>>>> the
>>>>> heap on a System.gc().
>>>>>
>>>>>            
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>>              
>>>>> I like the structure of the original webrev with regard to the logic for
>>>>> using FreeRation.  It's simpler than embedding it in the
>>>>> PSAdaptivesizePolicy.
>>>>>
>>>>>
>>>>> 243     if (UseFreeRatioOnlyInSystemGCForParallelGC&&
>>>>> 245           gc_cause == GCCause::_java_lang_system_gc)) {
>>>>>          compute_new_size();<<<<<<<<    generalization of
>>>>>              <<<<<<<<    try_to_shrink_by_free_ratio()
>>>>> 248     } else {
>>>>>          use current UseAdaptiveSizePolicy
>>>>>        }
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>            
>>      

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20100503/77475c14/attachment.htm>


More information about the hotspot-gc-dev mailing list