RFC: JEP: Remove the Concurrent Mark Sweep Garbage Collector

[charlie hunt]

Hi Kirk,

A couple questions ...

Could you expand on this statement?

> [....] the big issue is that I’ve not been able to get the [G1] collector to scale down to the point where it overlaps with the parallel collector. It is this gap that CMS fills.
I am not sure clear on what you mean when you say "scale down to the 
point where it overlaps with the parallel collector".

Also, you mentioned PeopleSoft as an example application where you do 
not see an alternative collector. Are there other applications you could 
mention as an example, or some common characteristics of this/these 
kind(s) of application?  I would like to see if we could either run an 
existing app or construct something that could exhibit your observation(s).

thanks,

charlie

On 8/8/19 12:59 PM, Kirk Pepperdine wrote:
> Hi Claes,
>
> Thanks for your interest.
>
>
>> On Aug 8, 2019, at 10:33 AM, Claes Redestad <claes.redestad at oracle.com> wrote:
>>
>> Hi Kirk,
>>
>> sorry for barging in, but this genuinely piqued my interest.
>>
>> On 2019-08-08 18:37, Kirk Pepperdine wrote:
>>> Hi Thomas,
>>> "n the meantime the Oracle garbage collection team introduced a new garbage collector, ZGC, and Red Hat contributed the Shenandoah collector. Oracle further improved G1, which has been its designated successor since initial introduction in JDK6u14, to a point where we believe there is little reason to use the CMS collector in deployments.”
>>> I fear my experience in tuning GC 1000s of JVMs leaves me at odds with the premise that there is little reason to use CMS. In my experience CMS overheads are no where near the level of those seen with G1. This is not just my experience but there are other organizations that have reached the same conclusion. Further more, with the removal of CMS we are now recommending that customers consider Parallel GC as it offers a far better experience than G1. Again, I’m not alone is seeing this as a growing trend.
>> Which JDK version were these JVMs running? I'm curious if/how you've
>> taken into account the tuning work and improvements made to G1 in
>> recent releases in your assessments.
> To be fair I’ve not tested since JDK 12 though I didn’t see much in the way of improvement. I know things have improved in 13. However many clients are running in 8 and will be for some time to come. Others are sticking to LTS releases for what ever reasoning. But the big issue is that I’ve not been able to get the collector to scale down to the point where it overlaps with the parallel collector. It is this gap that CMS fills.. and it’s a very common gap for the apps that we are generally involved with (including a number of apps like PeopleSoft).
>>> Although I do have high hopes for both ZGC and Shenandoah, they are not an option for most sites at this point in time. I would suggested that depreciation of CMS was premature as there was no viable alternative. I would further suggest that removal is also premature as there is still no viable alternative for the majority of workloads that work exceptionally well with CMS.
>> Can you clarify why they aren't options at this point in time? Or why
>> you think they still won't be once CMS is actually removed, be it from
>> JDK 14 or a later release?
> As I stated, at this point in time these collectors are experimental options and thus I can’t recommend them to be used in production environments. Further more, all of the benchmarking suggests that applications will take a 10-15% hit in throughput. I take that to mean, a proportionate hit in the power the bill.
>
> Most of what I’ve stated are things that have been stated by myself and others when CMS depreciation was first announced. We did have a meeting while at JavaONE to discuss. Like I said, since then I’ve seem improvements but there just seem to be some overheads that are unavoidable when building a mostly concurrent collector. That coupled with the fact that for CMS, there is a range of tenured occupancy where it simply just works better than any other option.
>
> Kind regards,
> Kirk
>