JEP 173: Remove Rarely-Used Combinations of Garbage Collectors

[Kirk Pepperdine]

Hi Bengt,

I would politely suggest that it's too soon to depreciate iCMS. Until I'm convinced that G1 is a good replacement I'll still be recommending that certain customers continue to use it. My only other alternative is Zing.

Kind regards,
Kirk

On 2012-12-19, at 2:45 PM, Bengt Rutisson <bengt.rutisson at oracle.com> wrote:

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