RFC: JEP: Remove the Concurrent Mark Sweep Garbage Collector

[Kirk Pepperdine]

Hi Thomas,



> On Aug 14, 2019, at 5:55 AM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> 
> Hi Kirk,
> 
>  sorry for the late answer.

No worries and I appreciate your response.

Believe me, I have no great affinity for CMS, its improperly configured out of the box and most people, including many support organizations simply offer very very bad tuning advice… so moving to a collector that is more self tuned out of the box is a huge win…. But then, for many workloads it’s offered the best balance between pause times and overhead. Also, I look at the benchmarks that I’ve run in the past to be  are an indirect measure of electron budget so it’s not just about pause time nor is it just about throughput, it’s about the power and cooling bill.

As for the community picking up working on CMS. While in theory it’s possible, in practice it’s also possible that individuals could or might setup up but a more likely scenario is that those individuals would need to be sponsored by a larger organization that has the resources to help. But I believe you are correct on this point, at the end of the day, if we want CMS we’re going to have to step up and do something about it. I’ll start by restoring and rerunning some benchmarks with the most recent versions of G1 and see where that goes.

Kind regards,
Kirk

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