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

[Jon Masamitsu]

The 4.b approach seems like a workable approach although there
are a variety of ways to achieve it.  Some elements of 4.c might
be a good solution in some cases.  Working through some instances
will help me understand 4.b better.

With regard to Oracle being in a unique position to do this work,
we're likely in the best position to identify what needs to be done,
but I don't think it follows that we need to do all the work.   If
Oracle comes up with a list of tasks, others can join in to do the
tasks.

Jon


On 7/13/2016 9:38 AM, Volker Simonis 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
>>