JEP 173: Remove Rarely-Used Combinations of Garbage Collectors

[Jon Masamitsu]

On 12/17/12 20:24, Andrew Thompson wrote:
> Thanks for the clarification.
>
> Out of curiosity, is shrinking really a simple choice? Presumably leaving the heap larger means fewer collections and better performance overall if lots more garbage is created.

Hmmm.  Not sure I understand this question.
Using an implementation that allows shrinking
is a simple choice.  How it shrinks is more.

>
>
> Does this need some kind of goal specified on the command line beyond what's ready possible? (mx, ms, Min/MaxFreeHeapRatio seem like enough).

Yes, those parameters are enough but the implementation in the
case where CMS is  the collector for the old gen and a full
GC is invoked does not use those parameters.

CMS gen uses free lists so shrinking is more than
just bumping down the high end of the generation.
CMS gen shrink() doesn't do any shrinking.

When full compacting collection is done, shrinking can
be done by just bumping down the high end of the
generation, but the CMS gen shrink() was being
called instead of the shrink() that does bump down
the high end.

Jon

>
> On Dec 17, 2012, at 4:27 PM, Jon Masamitsu<jon.masamitsu at oracle.com>  wrote:
>
>> Ramki,
>>
>> There is an unintended consequence :-) of having defined a compute_new_size()
>> for the CMS gen.  That compute_new_size() doesn't do shrinking and
>> gets called in the do_collection() when a full collection is done.  The result
>> is that even if the full collection results in lots of free space in the CMS
>> gen, there still isn't any shrinking.  I have a fix that hasn't been polished
>> yet.  Can't say it's coming soon but hopefully it's coming.
>>
>> Jon
>>
>> On 12/17/2012 12:05 PM, Srinivas Ramakrishna wrote:
>>> I suspect Andy (lordpixel) may be referring to CMS generally not giving old
>>> gen heao memory back to the OS even when applicatio
>>> footprint shrinks. I haven't ventured into CMS resizing code in a while,
>>> but i assumed that it would not be difficult to make it do so at
>>> the end of a sweep because of keeping a (hopefully) large contiguous free
>>> block at the high end of the heap. I don't think though that
>>> heap shrinking was ever a priority for the server environments in which CMS
>>> mostly got used, so it never really got done.
>>>
>>> -- ramki
>>>
>>> On Mon, Dec 17, 2012 at 10:38 AM, Jon Masamitsu<jon.masamitsu at oracle.com>wrote:
>>>
>>>> -XX:+UseParNewGC  will give you a parallel young gen collector
>>>> plus the serial old gen collector.   It does not have all the features
>>>> that -XX:+UseParallelGC has (for example, does not have support
>>>> for -XX:+UseNUMA).   It actually is one of the combinations that
>>>> we would like to remove.
>>>>
>>>> Jon
>>>>
>>>>
>>>> On 12/14/2012 9:24 PM, lordpixel at me.com wrote:
>>>>
>>>>> For whatever reason I assumed this was only a collector for the young
>>>>> generation... is that wrong? Even if it does give memory back, for one of
>>>>> my apps at least its the old generation that needs to shrink.
>>>>>
>>>>> On Dec 14, 2012, at 10:52 AM, Jon Masamitsu<jon.masamitsu@**oracle.com<jon.masamitsu at oracle.com>>
>>>>>   wrote:
>>>>>
>>>>>   -XX:+UseParNewGC
>>>>> AndyT (lordpixel - the cat who walks through walls)
>>>>> A little bigger on the inside
>>>>>
>>>>>          (see you later space cowboy, you can't take the sky from me)
>>>>>
>>>>>
>>>>>
>>>>>