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

Wed Jul 13 16:38:55 UTC 2016

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
>