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.org/pipermail/hotspot-gc-dev/attachments/20100503/77475c14/attachment.htm>
More information about the hotspot-gc-dev
mailing list