JEP 291: Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector

[Martijn Verburg]

Hi all,

We are now constantly asked to tune G1 for customers and have found that
even with our most advanced analytics (in combination with some of the
common and more esoteric tuning options), we are unable to get G1 to
outperform CMS for *certain* use cases. Several customers have therefore
reverted to CMS and are very interested in its future (as consumers).

jClarity is not (at this stage) of the size where we can contribute a lot
of effort for the native code refactor/maintenance, but we can definitely
assist with tooling and statistical analysis of the results of any
refactoring and compare and contrast that against the existing
implementation.  We're also happy to lend our tooling to others who are
looking to understand G1 better (we have a free license programme for OSS,
especially OpenJDK developers).

Several members of the Adoption Group have also started a new initiative
(not an official OpenJDK project yet) to provide a build farm for the
OpenJDK community so that some of the more experimental forests can be
built and tested on a wide range of platforms. We have Mac OS X, Windows,
Linux variants, PowerPC, ARM etc, and expect to release this to the broader
OpenJDK community in the next two weeks, so I'm confident we will have
decent infrastructure to support that aspect of a refactor.

Cheers,
Martijn

On 7 April 2017 at 00:54, Jeremy Manson <jeremymanson at google.com> wrote:

> Since I was the one driving conversations when we discussed this 6 months
> ago, I should give an update from our end.
>
> After internal conversations, we decided that supporting CMS in any sort of
> ongoing fashion should be a last resort after we try getting G1 to do what
> we need it to do.  Our belief is that fewer collectors is better.
>
> We spent some time over the last few months coordinating with some of the
> folks at Oracle and experimenting to see if there were plausible ways
> forward with G1.  We couldn't find anything obvious.
>
> I spent some time last week talking with Tony Printezis, who had a few
> concrete ideas we had not tried.  Unfortunately, our lead (Jungwoo) is now
> moving on, so we are left with a person-doing-this-shaped hole (by the way
> - we're hiring for people to work on GC, if you happen to know anyone!).
> We have someone who can step in, but she has to get up to speed.  That's
> the current status.
>
> The short of it is: We are still willing to contribute work to support CMS,
> but we want to make sure we've done our due diligence on G1 first.  Our
> belief has been that the JDK 10 timeframe is long enough that we don't have
> to make this decision hurriedly.
>
> Jeremy
>
> On Thu, Apr 6, 2017 at 2:37 AM, Roman Kennke <rkennke at redhat.com> wrote:
>
> >
> > > 2017/4/5 1:29:28 -0700, aph at redhat.com:
> > >> On 05/04/17 08:45, Roman Kennke wrote:
> > >>> I'd say it's too early to talk about removing CMS. And, to be
> honest, I
> > >>> even question the move to deprecate it. What's going to happen if
> > >>> somebody actually takes over CMS maintainership? Un-deprecate it?
> > >> Indeed.  We need to think about this first.  I expect that there
> > >> will be someone interested enough to keep it going.
> > > Since this JEP was posted last summer we've had several discussions
> > > aimed at identifying a new maintainer for CMS, on the hotspot-gc-dev
> > > list [1][2] and in open meetings whose minutes are attached to the
> > > JEP issue [3].
> > >
> > > So far, no one has stepped up.
> > >
> > > If someone does step up soon then I expect the owner of this JEP will
> > > withdraw it.  If someone does so later on then CMS can be un-deprecated
> > > at that time.  In any case, Oracle does intend to stop maintaining CMS
> > > at some point in the not-to-distant future, and if no one ever steps up
> > > then we'll remove the code.
> >
> > Ok, I'll bite. I've heard a lot of people saying that they're interested
> > in keeping it alive, but no-one stepped up yet. I can say that I
> > wouldn't step up personally and take all of it. But I'd certainly
> > participate in such an effort. (In a sense I'm already doing it by
> > working on the GC interface). So why not pull our resources together and
> > do it as a shared/community effort? Then it probably doesn't take that
> > much from every single person/entity involved?
> >
> > From the top off my head, here's some items that would need to be done:
> > 1. continuous build with CMS turned on (assuming it can be disabled by a
> > build-time switch)
> > 2. fix occasional build failure (caused by changes in, e.g., the GC
> > interfaces or other runtime stuff)
> > 3. run tests with CMS
> > 4 triage bug reports
> > 5 fix bugs
> >
> > I have certainly missed some aspects? Please feel free to add them!
> >
> > CMS is a pretty mature code base, so I'd expect most work in 1 and 3
> > (which should be mostly automated after initial set-up), and 2 (which
> > shouldn't be very hard). 4 is also not very difficult. If something
> > comes up in 5, it's probably very hard.
> >
> > I'm not afraid to touch GC code, so I'd be willing to participate in
> > anything code related (e.g. 2 and 5).
> >
> > Oracle: you folks probably have CMS specific tests that are not in
> > OpenJDK yet? If so, would you be willing to contribute those?
> >
> > Everybody (I've seen Google, jClarity, Twitter, SAP and a bunch of
> > individuals involved in discussions): who else would be willing to
> > contribute? And in which way?
> >
> > Best regards, Roman
> >
> >
>