JEP 173: Remove Rarely-Used Combinations of Garbage Collectors

[Bengt Rutisson]

Hi Kirk,

Deprecating iCMS  accomplishes two things. First, it is a clear 
statement to users of iCMS that this is a collector they should try to 
move off of. We are not actively developing it and we can not guarantee 
the quality of it. This is already the case. Deprecating it just make 
people aware of this fact.

Second, it gives users a chance to report actual issues with switching 
from iCMS to CMS or G1 before we remove the implementation. In this mail 
thread there are no comparisons between iCMS and CMS or G1. So we really 
don't know if there are any issues. So far I have not seen any evidence 
that iCMS can not be replaced by CMS or G1.

I admit that there probably is no clear definition of what "deprecated" 
means but from my point of view I would say that it is likely that we 
will not remove iCMS until JDK9. Which gives users at least 2.5 years to 
adjust.

By deprecating iCMS the users of it will be more motivated to try CMS or 
G1 out and this will hopefully give us useful feedback to what we need 
to fix (if anything) in those collectors.

This is a slower path than I was hoping for, but it is still one step in 
a direction we need to go. We need to get to a situation where we have a 
small enough set of GC combinations that we can actually support and 
sustain them in a reasonable way.

Bengt

On 12/19/12 3:58 PM, Kirk Pepperdine wrote:
> 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)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>