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

[Jeremy Manson]

I largely agree with Volker.

The adoption of our (or someone else's) patch for JDK-8130200 was one of
the things I was thinking about when I mentioned that doing this could
provide CMS with a jolt of energy.  We have a few other goodies we've been
holding back, too.

I continue to want to have a meeting where interested parties talk about
this.  There is only a finite amount that can get decided on an email
thread.  It sounds like Volker might be interested in that, too.  I assume
Jon would be, and Kirk.  Anyone else?

Jeremy



On Wed, Jul 13, 2016 at 9:38 AM, Volker Simonis <volker.simonis at gmail.com>
wrote:

> Hi everybody,
>
> I'm afraid this discussion is degenerating into a CMS vs. G1 flame war :)
>
> I think instead we should rather focus on the consequences of JEP 291
> and how to mitigate them.
>
> 1. As Mark correctly noticed, Oracle has every right to drop CMS
> support in its commercial/proprietary Java offering. Any complaints
> against this decision should be addressed directly to Oracle and not
> to any OpenJDK mailing list.
>
> 2. Removing the CMS code from a specific OpenJDK release project is a
> different story because the OpenJDK project is a community-driven,
> open source project (albeit dominated by Oracle :)
>
> 3. We should therefore concentrate on finding a way of
> separating/isolating the CMS code from the other GC code in good faith
> and in a way that:
>  - Oracle can easily assemble its commercial/proprietary Java
> offerings *WITHOUT* CMS
>  - anybody else can easily assemble a Java version from the OpenJDK
> sources *WITH* CMS support
>
> 4. To achieve this, several proposals have been posted to this and
> another, older mail thread [1]:
>  a. Disable CMS by a constant command line option. This seems to be
> not acceptable to Oracle according to Jon.
>  b. Disable CMS at build time (e.g. as it has been done for many years
> with the CPP-Interpreter: --with-jvm-interpreter=cpp). This seems to
> be the most realistic approach although the details about how to
> effectively reorganize the CMS code still have to be figured out.
>  c. Refactor both G1 and CMS (and potentially other GCs) to use a
> common, still to be defined, GC interface and move the CMS code out
> into its own repository from where it can be plugged in into a vanilla
> OpenJDK build. This seems highly desirable from a software engineering
> perspective (and would also benefit third-party GCs like Shenandoah)
> but unfortunately it is also a little unrealistic, giving the current
> amount of resources and funding for such a project.
>
> As I already wrote in [1] SAP is supporting CMS and will probably do
> so for quite some time, so we are highly interested in keeping the CMS
> code *INSIDE* the OpenJDK release projects even after Java 9. So I
> would strongly vote for option 4.b above! Others like Twitter, RedHat
> and Google have expressed similar intents and interests as far as I've
> understood. Speaking for SAP, I can imagine that we will be doing
> regular (nightly) builds with CMS enabled and quickly fix new problems
> caused by changes in shared code once we're there. We are already
> successfully doing this for our AIX/PowerPC porting platforms since
> years (and we did support the before mentioned CPP interpreter for
> quite some time following the same model).
>
> Realistically (given the current infrastructure and resource
> constraints), the initial CMS refactoring should and can only be done
> by Oracle. Taking into account that Oracle has initiated this JEP and
> will be the only beneficiary of it I think that's just fair. Of course
> we (and probably others from the community) are willing to assist.
>
> Finally, this JEP shouldn't be seen solely as a threat. It is also a
> big chance for the future development of CMS. Enhancements like
> "JDK-8130200: Parallelize the Full GC Phase in CMS" [2] can be
> probably implemented and/or integrated a lot easier and faster, once
> CMS is separated and not controlled by Oracle any more.
>
> Regards,
> Volker
>
> [1]
> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-June/thread.html#18353
> [2] https://bugs.openjdk.java.net/browse/JDK-8130200
>
> On Mon, Jul 11, 2016 at 10:40 PM, Jungwoo Ha <jwha at google.com> wrote:
> > Fundamentally, G1's write-barrier is more expensive and has more
> > data-structure to maintain during the GC. Thus, CPU usage & VM memory
> > overhead is greater than the CMS by nature.
> > I can see that this can be reduced, but I am a bit skeptical that it can
> > eventually be on par with CMS.
> > While some users are willing to spend more resources for GC to gain
> latency
> > guarantee and ease of tuning, our users are mostly tight on resources and
> > are hesitant to increase any CPU/memory usage.
> >
> >
> >
> > On Mon, Jul 11, 2016 at 11:48 AM, <ecki at zusammenkunft.net> wrote:
> >>
> >> Hello, just an unsientific oppinion, if G1 really would get so much
> >> attention that it improves beond the CMS sweetspots, then I could
> understand
> >> Oracle to abandon CMS, but besides normal maintenance work it somehow
> does
> >> not look like there is bigger progress in G1. For example will we ever
> see a
> >> parallel FullGC (beeing a fallback when fragmentation by humongus
> >> allocations strike).
> >>
> >> Also the automatic tuning around pause goals seem to fail rather often.
> >> Some consolidated work to make the predictions a bit more robust would
> be
> >> good.
> >>
> >> Having said that CMS is not better in this areas (but people are used to
> >> tune it).
> >>
> >> And just to be constructive: alternative to prolonging CMS life would be
> >> to heavily invest into G1 by all parties (especially Google and SAP
> since
> >> IBM has already their own battlefield).
> >>
> >> Gruss
> >> Bernd
> >> --
> >> http://bernd.eckenfels.net
> >>
> >> -----Original Message-----
> >> From: Jeremy Manson <jeremymanson at google.com>
> >> To: "kirk.pepperdine at gmail.com" <kirk.pepperdine at gmail.com>
> >> Cc: "hotspot-gc-dev at openjdk.java.net openjdk.java.net"
> >> <hotspot-gc-dev at openjdk.java.net>
> >> Sent: Mo., 11 Juli 2016 17:46
> >> Subject: Re: JEP 291: Deprecate the Concurrent Mark Sweep (CMS) Garbage
> >> Collector
> >>
> >> To Kirk's point about performance - in fact, we have performance-related
> >> fixes to CMS we haven't been able to send upstream because they are too
> >> invasive, and (quite rationally) no one wanted to make invasive changes
> to
> >> a codebase on life support.
> >>
> >> So, we have concrete examples of ways in which it will get faster
> >> relatively quickly, if people other than us want this.
> >>
> >> Jeremy
> >>
> >> On Sat, Jul 9, 2016 at 5:41 AM, kirk.pepperdine at gmail.com <
> >> kirk.pepperdine at gmail.com> wrote:
> >>
> >> > Hi Jeremy,
> >> >
> >> > I’m also assessing my ability to contribute to maintaining CMS. IMO,
> >> > there
> >> > are still a number of things that can be done to keep the collector
> >> > competitive.
> >> >
> >> > Kind regards,
> >> > Kirk Pepperdine
> >> >
> >> > On Jul 8, 2016, at 8:46 PM, Jeremy Manson <jeremymanson at google.com>
> >> > wrote:
> >> >
> >> > Hey folks,
> >> >
> >> > We are interested in an actively maintained CMS.  It's the primary
> >> > collector used in our services, and we believe we will incur a
> >> > meaningful
> >> > performance cost across our fleet if we need to migrate to G1.
> >> >
> >> > We'd be interested in participating in maintenance, but it will be an
> >> > uphill slog if we are the only ones.  Who else might be interested?  I
> >> > think there would be value in having that conversation, and I'd be
> happy
> >> > to
> >> > organize a meeting (unfortunately, I have to miss the JVMLS this year,
> >> > but
> >> > I'd be happy to do it out of band).
> >> >
> >> > There could even be advantages for the community if it is no longer
> part
> >> > of Oracle's build, but it remains community supported.  Because it has
> >> > been
> >> > on life support for the past few years, the upstream team has shied
> away
> >> > from making substantial changes.  This could provide it with a jolt of
> >> > energy.
> >> >
> >> > Any takers?
> >> >
> >> > Jeremy
> >> >
> >> >
> >> > On Fri, Jul 1, 2016 at 2:08 PM, <mark.reinhold at oracle.com> wrote:
> >> >
> >> >> 2016/7/1 1:50:41 -0700, aph at redhat.com:
> >> >> > On 30/06/16 22:35, mark.reinhold at oracle.com wrote:
> >> >> >> New JEP Candidate: http://openjdk.java.net/jeps/291
> >> >> >
> >> >> > I think that there is likely to be a fair amount of push-back
> against
> >> >> > this one.  I understand that the GC team has to be responsible for
> >> >> > this decision, given that they have to support it.  But there has
> to
> >> >> > be at least a possibility that OpenJDK support for CMS might not be
> >> >> > ended, and Oracle is not necessarily the only company involved in
> >> >> > this.
> >> >>
> >> >> I think that's well understood.
> >> >>
> >> >> There are limits to what can be expressed within the structure of a
> JEP
> >> >> so, for clarity's sake, here's my take on this.  Jon will correct me
> if
> >> >> I've got any of it wrong, I'm sure.
> >> >>
> >> >> Oracle's GC team is intensely focused on improving the G1 collector,
> so
> >> >> they're trying to reduce the amount of time they spend maintaining
> CMS.
> >> >> At the very least, therefore, they will deprecate CMS in Oracle's
> JDK 9
> >> >> product builds and then, most likely but depending upon end-user and
> >> >> customer feedback, remove it entirely from Oracle's JDK 10 builds.
> >> >>
> >> >> Whether and when this happens is a decision for Oracle to make, just
> as
> >> >> whether Red Hat ships an AArch64 build of JDK 9 is a decision for Red
> >> >> Hat to make.  I don't think this is controversial -- there's really
> no
> >> >> need for anyone to spin conspiracy theories about smoke-filled rooms
> in
> >> >> Redwood Shores (but go ahead and do that if it makes you feel
> better).
> >> >>
> >> >> The fate of the CMS GC code itself in any particular OpenJDK Release
> >> >> Project, or in any other OpenJDK Project for that matter, is a
> >> >> different
> >> >> question, about which JEP 291 was intended to prompt a wider
> >> >> discussion,
> >> >> as indeed it has.
> >> >>
> >> >> If a set of credible developers expresses a clear desire to maintain
> >> >> CMS
> >> >> after JDK 9 then all of us who work on this code base, regardless of
> >> >> employer, will find a way for that to happen.  Maybe the CMS code
> stays
> >> >> in JDK 9 and later Release Projects but is #ifdef'd out, or maybe it
> >> >> stays but the common GC interface is refactored so that other
> >> >> collectors
> >> >> (not just G1) can evolve more independently, or maybe the CMS code is
> >> >> removed from the mainline Release Projects but kept alive in a new
> side
> >> >> Project.  Exactly what happens depends mostly, I think, on who shows
> >> >> up.
> >> >>
> >> >> To put it another way, the question that JEP 291 is trying to ask is,
> >> >> "Does anybody outside of Oracle wish to take on the maintenance of
> CMS
> >> >> after JDK 9?  If so, then let's talk."
> >> >>
> >> >> Any takers?
> >> >>
> >> >> - Mark
> >> >>
> >> >
> >> >
> >> >
> >
> >
> >
> >
> > --
> > Jungwoo Ha | Java Platform Team | jwha at google.com
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20160713/12c743ee/attachment.htm>