RFC: JEP: Remove the Concurrent Mark Sweep Garbage Collector
thomas.schatzl at oracle.com
Wed Aug 14 12:55:27 UTC 2019
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.
,) together with the community; at the recent JVMLS there has been
a workshop that showed a selection of these G1 improvements since JDK8
(), 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
; feel free to ask about particulars.
; note that is a pure throughput load
More information about the hotspot-gc-dev