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

Thu Jul 14 07:42:26 UTC 2016

Happy to join in.

Cheers,
Martijn

On 14 July 2016 at 06:22, 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?
>
> 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/8170e71e/attachment.htm>