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

[Jeremy Manson]

If you folks are all going to be around at the JVMLS, maybe we can meet
around that time?  I wasn't going to go - I'm going on vacation that week -
but I'll be in town for most of it; I could either come for part, or host
something outside of JVMLS hours at Google (which is about a 10-15 minute
drive north).

Jeremy

On Thu, Jul 14, 2016 at 1:33 AM, Volker Simonis <volker.simonis at gmail.com>
wrote:

> On Thu, Jul 14, 2016 at 7:22 AM, Jeremy Manson <jeremymanson at google.com>
> wrote:
> > 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?
> >
>
> Yes, I am. And probably somebody from Twitter (CC'ed Tony), RedHat
> (CC'ed Andrew) and maybe Azul (CC'ed Gil) ?
>
> > 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/20160714/435a4739/attachment.htm>