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

[kirk at kodewerk.com]

Hi Bernd,

At the moment I cannot see how G1 could easily be made to be as efficient as CMS on certain hardware configurations. After having visualized how the G1 handles humongous allocations I can see a way that may reduce the number of allocation failures (due to fragmentation). Humungous blocks are allocated out of tenured space away from Survivor and Eden. Often this leaves a large gap between the top of survivor and the bottom tenured. It seems to me that it should be possible to fit humungous allocations in that gap.

That said, this isn’t the biggest problem on the block. The biggest problem from what I can see or guess at is some form of floating garbage similar to what we see in CMS. However with the G1 it is much more insidious in that some regions either rarely or never get collected resulting in that floating garbage hanging around for a long time. I have some experiments where triggering a Full GC results in an exact cleaning of heap and that always comes with reduced pause times. Combine this with, in just about every GC log I’ve looked at, object copy times dominate the pause time, and the conclusion I’ve come to is that this floating garbage adds to object copy times *and this floating garbage never goes away*.

So, what to do….. the only solution I’ve been able to make work on a fairly consistent basis is to try to balance settings between pause time goal, mixed collection ratio and the ripeness threshold in order to get the collector to more aggressively collect fewer regions more often. Of course this comes with higher overheads. In those cases reverting to CMS is often a big win. I can think of some possible changes to G1 that could help but I’m sure these changes would result in higher G1 overheads. So it’s a you can neither beat them or join them situation from what I can see so far.

Point is, I can understand the reasons to drop CMS and it would not be an unreasonable position to take or support only if G1 were truly ready to handle all of these cases. IMHO, G1 isn’t suited for a number of cases so dropping CMS seems a bit premature.

Kind regards,
Kirk

> On Jul 11, 2016, at 8:48 PM, 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
>>> 
>> 
>> 
>> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20160711/b8eb4a64/signature.asc>