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

[Jeremy Manson]

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