RFC: JEP: Remove the Concurrent Mark Sweep Garbage Collector

[Thomas Schatzl]

Hi Kirk,

   sorry for the late answer.

On 08.08.19 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 

Nobody is in any way guaranteeing that any of the many alternatives will 
be the absolute best garbage collector for all the applications out 
there ever written. That's impossible.

CMS has been available in Hotspot for 15+ years, and we understand that 
there is a lot of experience tuning that garbage collector; we also know 
that there are applications that have been specifically (re-)written to 
work best with CMS. Particularly these applications are unlikely to 
work better (for a particular measure of "better") on any different 
collector unless that (probably?) collector reimplements significant 
parts of CMS.

However we think that the overhead of one of the alternatives for these 
imho few applications is small enough even for those to be able to move 
away from CMS _now_.

I will adapt that paragraph in the JEP to make this more clear. Thanks 
for your feedback.

Looking in the bug tracker for particular issues, during the last two 
years of CMS deprecation we got very little actionable feedback from the 
community on what exactly G1 (in particular) is missing.
All of the example code we have run better than CMS with some G1 tuning 
(e.g. JDK-8062128; with jdk8!) or are simply throughput applications for 
which Parallel (e.g. JDK-8133055) is suited well.

In some other email you mentioned that most people are still at JDK8 
(which we know), and most people are only moving from one LTS versions 
to another (which we also know). CMS support is not going away in either 
8 or 11, and 17 will be released in two years.

Since CMS deprecation we demonstrated that we improved G1 a lot (e.g. 
[2],[3]) together with the community; at the recent JVMLS there has been 
a workshop that showed a selection of these G1 improvements since JDK8 
([0]), and an imho decent roadmap for the future to, among other things, 
with the community, address concerns that were described sufficiently so 
they can actually be worked on.

So I would like to reiterate Charlie's request to work with us to allow 
us to analyze these applications that exhibit your observations.

There has also always been the option to organize maintenance of CMS in 
the community, but nobody even stepped up starting to fix the 
long-standing existing known minor issues CMS (to get contributors to 
know CMS code and to give us confidence that these persons can take over 
maintenance of such a large component).

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

The answer to this is the same as it has been two years ago when CMS has 
been deprecated: work together with the community to evaluate, 
understand and try to address these issues if viable (e.g. Oracle is 
unlikely to directly reimplement CMS' free list memory management on top 
of G1 if this is the real problem).

As the JEP points out, CMS maintenance, e.g. adapting code to interface 
changes required by improvements to other components, fixing important 
issues, or even small improvements, but mostly testing, take up a lot of 
resources that we think could be better spent elsewhere.

Doing so seems better to me than relentlessly stating: "There is no 
viable alternative".

Thanks,
   Thomas

[0] 
http://mail.openjdk.java.net/pipermail/hotspot-gc-use/2019-August/002816.html 
; feel free to ask about particulars.
[2] https://www.youtube.com/watch?v=LppgqvKOUKsv
[3] 
https://www.optaplanner.org/blog/2019/01/17/HowMuchFasterIsJava11.html#table1 
; note that is a pure throughput load