JEP 173: Remove Rarely-Used Combinations of Garbage Collectors

[Bengt Rutisson]

Hi again,

Another heads up. I think we still have some things to discuss to 
finalize the discussion around iCMS, but as a first step I sent out a 
webrev where we issue a warning that iCMS is deprecated.

Thanks,
Bengt

On 12/18/12 3:07 PM, Bengt Rutisson wrote:
>
> Hi all,
>
> Just a heads up. I just send out a webrev on 
> hotspot-gc-dev at openjdk.java.net for deprecating the DefNew + CMS and 
> ParNew + SerialOld combinations. The email thread is called "Request 
> for review (S): 8003820: Deprecate untested and rarely used GC 
> combinations".
>
> This does not touch iCMS, which seems to have been the most sensitive 
> topic of the JEP. I will come back with other review on that.
>
> Thanks,
> Bengt
>
> On 12/18/12 5:24 AM, 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.
>>
>> Does this need some kind of goal specified on the command line beyond 
>> what's ready possible? (mx, ms, Min/MaxFreeHeapRatio seem like enough).
>>
>> 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)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>