<div dir="ltr">I largely agree with Volker.  <div><br></div><div>The adoption of our (or someone else's) patch for <span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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?</span></div><div><span style="font-size:12.8px"><br></span><span style="font-size:12.8px">Jeremy</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 13, 2016 at 9:38 AM, Volker Simonis <span dir="ltr"><<a href="mailto:volker.simonis@gmail.com" target="_blank">volker.simonis@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi everybody,<br>
<br>
I'm afraid this discussion is degenerating into a CMS vs. G1 flame war :)<br>
<br>
I think instead we should rather focus on the consequences of JEP 291<br>
and how to mitigate them.<br>
<br>
1. As Mark correctly noticed, Oracle has every right to drop CMS<br>
support in its commercial/proprietary Java offering. Any complaints<br>
against this decision should be addressed directly to Oracle and not<br>
to any OpenJDK mailing list.<br>
<br>
2. Removing the CMS code from a specific OpenJDK release project is a<br>
different story because the OpenJDK project is a community-driven,<br>
open source project (albeit dominated by Oracle :)<br>
<br>
3. We should therefore concentrate on finding a way of<br>
separating/isolating the CMS code from the other GC code in good faith<br>
and in a way that:<br>
 - Oracle can easily assemble its commercial/proprietary Java<br>
offerings *WITHOUT* CMS<br>
 - anybody else can easily assemble a Java version from the OpenJDK<br>
sources *WITH* CMS support<br>
<br>
4. To achieve this, several proposals have been posted to this and<br>
another, older mail thread [1]:<br>
 a. Disable CMS by a constant command line option. This seems to be<br>
not acceptable to Oracle according to Jon.<br>
 b. Disable CMS at build time (e.g. as it has been done for many years<br>
with the CPP-Interpreter: --with-jvm-interpreter=cpp). This seems to<br>
be the most realistic approach although the details about how to<br>
effectively reorganize the CMS code still have to be figured out.<br>
 c. Refactor both G1 and CMS (and potentially other GCs) to use a<br>
common, still to be defined, GC interface and move the CMS code out<br>
into its own repository from where it can be plugged in into a vanilla<br>
OpenJDK build. This seems highly desirable from a software engineering<br>
perspective (and would also benefit third-party GCs like Shenandoah)<br>
but unfortunately it is also a little unrealistic, giving the current<br>
amount of resources and funding for such a project.<br>
<br>
As I already wrote in [1] SAP is supporting CMS and will probably do<br>
so for quite some time, so we are highly interested in keeping the CMS<br>
code *INSIDE* the OpenJDK release projects even after Java 9. So I<br>
would strongly vote for option 4.b above! Others like Twitter, RedHat<br>
and Google have expressed similar intents and interests as far as I've<br>
understood. Speaking for SAP, I can imagine that we will be doing<br>
regular (nightly) builds with CMS enabled and quickly fix new problems<br>
caused by changes in shared code once we're there. We are already<br>
successfully doing this for our AIX/PowerPC porting platforms since<br>
years (and we did support the before mentioned CPP interpreter for<br>
quite some time following the same model).<br>
<br>
Realistically (given the current infrastructure and resource<br>
constraints), the initial CMS refactoring should and can only be done<br>
by Oracle. Taking into account that Oracle has initiated this JEP and<br>
will be the only beneficiary of it I think that's just fair. Of course<br>
we (and probably others from the community) are willing to assist.<br>
<br>
Finally, this JEP shouldn't be seen solely as a threat. It is also a<br>
big chance for the future development of CMS. Enhancements like<br>
"JDK-8130200: Parallelize the Full GC Phase in CMS" [2] can be<br>
probably implemented and/or integrated a lot easier and faster, once<br>
CMS is separated and not controlled by Oracle any more.<br>
<br>
Regards,<br>
Volker<br>
<br>
[1] <a href="http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-June/thread.html#18353" rel="noreferrer" target="_blank">http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-June/thread.html#18353</a><br>
[2] <a href="https://bugs.openjdk.java.net/browse/JDK-8130200" rel="noreferrer" target="_blank">https://bugs.openjdk.java.net/browse/JDK-8130200</a><br>
<div class="HOEnZb"><div class="h5"><br>
On Mon, Jul 11, 2016 at 10:40 PM, Jungwoo Ha <<a href="mailto:jwha@google.com">jwha@google.com</a>> wrote:<br>
> Fundamentally, G1's write-barrier is more expensive and has more<br>
> data-structure to maintain during the GC. Thus, CPU usage & VM memory<br>
> overhead is greater than the CMS by nature.<br>
> I can see that this can be reduced, but I am a bit skeptical that it can<br>
> eventually be on par with CMS.<br>
> While some users are willing to spend more resources for GC to gain latency<br>
> guarantee and ease of tuning, our users are mostly tight on resources and<br>
> are hesitant to increase any CPU/memory usage.<br>
><br>
><br>
><br>
> On Mon, Jul 11, 2016 at 11:48 AM, <<a href="mailto:ecki@zusammenkunft.net">ecki@zusammenkunft.net</a>> wrote:<br>
>><br>
>> Hello, just an unsientific oppinion, if G1 really would get so much<br>
>> attention that it improves beond the CMS sweetspots, then I could understand<br>
>> Oracle to abandon CMS, but besides normal maintenance work it somehow does<br>
>> not look like there is bigger progress in G1. For example will we ever see a<br>
>> parallel FullGC (beeing a fallback when fragmentation by humongus<br>
>> allocations strike).<br>
>><br>
>> Also the automatic tuning around pause goals seem to fail rather often.<br>
>> Some consolidated work to make the predictions a bit more robust would be<br>
>> good.<br>
>><br>
>> Having said that CMS is not better in this areas (but people are used to<br>
>> tune it).<br>
>><br>
>> And just to be constructive: alternative to prolonging CMS life would be<br>
>> to heavily invest into G1 by all parties (especially Google and SAP since<br>
>> IBM has already their own battlefield).<br>
>><br>
>> Gruss<br>
>> Bernd<br>
>> --<br>
>> <a href="http://bernd.eckenfels.net" rel="noreferrer" target="_blank">http://bernd.eckenfels.net</a><br>
>><br>
>> -----Original Message-----<br>
>> From: Jeremy Manson <<a href="mailto:jeremymanson@google.com">jeremymanson@google.com</a>><br>
>> To: "<a href="mailto:kirk.pepperdine@gmail.com">kirk.pepperdine@gmail.com</a>" <<a href="mailto:kirk.pepperdine@gmail.com">kirk.pepperdine@gmail.com</a>><br>
>> Cc: "<a href="mailto:hotspot-gc-dev@openjdk.java.net">hotspot-gc-dev@openjdk.java.net</a> <a href="http://openjdk.java.net" rel="noreferrer" target="_blank">openjdk.java.net</a>"<br>
>> <<a href="mailto:hotspot-gc-dev@openjdk.java.net">hotspot-gc-dev@openjdk.java.net</a>><br>
>> Sent: Mo., 11 Juli 2016 17:46<br>
>> Subject: Re: JEP 291: Deprecate the Concurrent Mark Sweep (CMS) Garbage<br>
>> Collector<br>
>><br>
>> To Kirk's point about performance - in fact, we have performance-related<br>
>> fixes to CMS we haven't been able to send upstream because they are too<br>
>> invasive, and (quite rationally) no one wanted to make invasive changes to<br>
>> a codebase on life support.<br>
>><br>
>> So, we have concrete examples of ways in which it will get faster<br>
>> relatively quickly, if people other than us want this.<br>
>><br>
>> Jeremy<br>
>><br>
>> On Sat, Jul 9, 2016 at 5:41 AM, <a href="mailto:kirk.pepperdine@gmail.com">kirk.pepperdine@gmail.com</a> <<br>
>> <a href="mailto:kirk.pepperdine@gmail.com">kirk.pepperdine@gmail.com</a>> wrote:<br>
>><br>
>> > Hi Jeremy,<br>
>> ><br>
>> > I’m also assessing my ability to contribute to maintaining CMS. IMO,<br>
>> > there<br>
>> > are still a number of things that can be done to keep the collector<br>
>> > competitive.<br>
>> ><br>
>> > Kind regards,<br>
>> > Kirk Pepperdine<br>
>> ><br>
>> > On Jul 8, 2016, at 8:46 PM, Jeremy Manson <<a href="mailto:jeremymanson@google.com">jeremymanson@google.com</a>><br>
>> > wrote:<br>
>> ><br>
>> > Hey folks,<br>
>> ><br>
>> > We are interested in an actively maintained CMS.  It's the primary<br>
>> > collector used in our services, and we believe we will incur a<br>
>> > meaningful<br>
>> > performance cost across our fleet if we need to migrate to G1.<br>
>> ><br>
>> > We'd be interested in participating in maintenance, but it will be an<br>
>> > uphill slog if we are the only ones.  Who else might be interested?  I<br>
>> > think there would be value in having that conversation, and I'd be happy<br>
>> > to<br>
>> > organize a meeting (unfortunately, I have to miss the JVMLS this year,<br>
>> > but<br>
>> > I'd be happy to do it out of band).<br>
>> ><br>
>> > There could even be advantages for the community if it is no longer part<br>
>> > of Oracle's build, but it remains community supported.  Because it has<br>
>> > been<br>
>> > on life support for the past few years, the upstream team has shied away<br>
>> > from making substantial changes.  This could provide it with a jolt of<br>
>> > energy.<br>
>> ><br>
>> > Any takers?<br>
>> ><br>
>> > Jeremy<br>
>> ><br>
>> ><br>
>> > On Fri, Jul 1, 2016 at 2:08 PM, <<a href="mailto:mark.reinhold@oracle.com">mark.reinhold@oracle.com</a>> wrote:<br>
>> ><br>
>> >> 2016/7/1 1:50:41 -0700, <a href="mailto:aph@redhat.com">aph@redhat.com</a>:<br>
>> >> > On 30/06/16 22:35, <a href="mailto:mark.reinhold@oracle.com">mark.reinhold@oracle.com</a> wrote:<br>
>> >> >> New JEP Candidate: <a href="http://openjdk.java.net/jeps/291" rel="noreferrer" target="_blank">http://openjdk.java.net/jeps/291</a><br>
>> >> ><br>
>> >> > I think that there is likely to be a fair amount of push-back against<br>
>> >> > this one.  I understand that the GC team has to be responsible for<br>
>> >> > this decision, given that they have to support it.  But there has to<br>
>> >> > be at least a possibility that OpenJDK support for CMS might not be<br>
>> >> > ended, and Oracle is not necessarily the only company involved in<br>
>> >> > this.<br>
>> >><br>
>> >> I think that's well understood.<br>
>> >><br>
>> >> There are limits to what can be expressed within the structure of a JEP<br>
>> >> so, for clarity's sake, here's my take on this.  Jon will correct me if<br>
>> >> I've got any of it wrong, I'm sure.<br>
>> >><br>
>> >> Oracle's GC team is intensely focused on improving the G1 collector, so<br>
>> >> they're trying to reduce the amount of time they spend maintaining CMS.<br>
>> >> At the very least, therefore, they will deprecate CMS in Oracle's JDK 9<br>
>> >> product builds and then, most likely but depending upon end-user and<br>
>> >> customer feedback, remove it entirely from Oracle's JDK 10 builds.<br>
>> >><br>
>> >> Whether and when this happens is a decision for Oracle to make, just as<br>
>> >> whether Red Hat ships an AArch64 build of JDK 9 is a decision for Red<br>
>> >> Hat to make.  I don't think this is controversial -- there's really no<br>
>> >> need for anyone to spin conspiracy theories about smoke-filled rooms in<br>
>> >> Redwood Shores (but go ahead and do that if it makes you feel better).<br>
>> >><br>
>> >> The fate of the CMS GC code itself in any particular OpenJDK Release<br>
>> >> Project, or in any other OpenJDK Project for that matter, is a<br>
>> >> different<br>
>> >> question, about which JEP 291 was intended to prompt a wider<br>
>> >> discussion,<br>
>> >> as indeed it has.<br>
>> >><br>
>> >> If a set of credible developers expresses a clear desire to maintain<br>
>> >> CMS<br>
>> >> after JDK 9 then all of us who work on this code base, regardless of<br>
>> >> employer, will find a way for that to happen.  Maybe the CMS code stays<br>
>> >> in JDK 9 and later Release Projects but is #ifdef'd out, or maybe it<br>
>> >> stays but the common GC interface is refactored so that other<br>
>> >> collectors<br>
>> >> (not just G1) can evolve more independently, or maybe the CMS code is<br>
>> >> removed from the mainline Release Projects but kept alive in a new side<br>
>> >> Project.  Exactly what happens depends mostly, I think, on who shows<br>
>> >> up.<br>
>> >><br>
>> >> To put it another way, the question that JEP 291 is trying to ask is,<br>
>> >> "Does anybody outside of Oracle wish to take on the maintenance of CMS<br>
>> >> after JDK 9?  If so, then let's talk."<br>
>> >><br>
>> >> Any takers?<br>
>> >><br>
>> >> - Mark<br>
>> >><br>
>> ><br>
>> ><br>
>> ><br>
><br>
><br>
><br>
><br>
> --<br>
> Jungwoo Ha | Java Platform Team | <a href="mailto:jwha@google.com">jwha@google.com</a><br>
><br>
</div></div></blockquote></div><br></div>