<div dir="ltr">If you folks are all going to be around at the JVMLS, maybe we can meet around that time? I wasn't going to go - I'm going on vacation that week - but I'll be in town for most of it; I could either come for part, or host something outside of JVMLS hours at Google (which is about a 10-15 minute drive north).<div><br></div><div>Jeremy</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 14, 2016 at 1:33 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"><span class="">On Thu, Jul 14, 2016 at 7:22 AM, Jeremy Manson <<a href="mailto:jeremymanson@google.com">jeremymanson@google.com</a>> wrote:<br>
> I largely agree with Volker.<br>
><br>
> The adoption of our (or someone else's) patch for JDK-8130200 was one of the<br>
> things I was thinking about when I mentioned that doing this could provide<br>
> CMS with a jolt of energy. We have a few other goodies we've been holding<br>
> back, too.<br>
><br>
> I continue to want to have a meeting where interested parties talk about<br>
> this. There is only a finite amount that can get decided on an email<br>
> thread. It sounds like Volker might be interested in that, too. I assume<br>
> Jon would be, and Kirk. Anyone else?<br>
><br>
<br>
</span>Yes, I am. And probably somebody from Twitter (CC'ed Tony), RedHat<br>
(CC'ed Andrew) and maybe Azul (CC'ed Gil) ?<br>
<div class="HOEnZb"><div class="h5"><br>
> Jeremy<br>
><br>
><br>
><br>
> On Wed, Jul 13, 2016 at 9:38 AM, Volker Simonis <<a href="mailto:volker.simonis@gmail.com">volker.simonis@gmail.com</a>><br>
> wrote:<br>
>><br>
>> 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]<br>
>> <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>
>><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<br>
>> > latency<br>
>> > guarantee and ease of tuning, our users are mostly tight on resources<br>
>> > 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<br>
>> >> understand<br>
>> >> Oracle to abandon CMS, but besides normal maintenance work it somehow<br>
>> >> does<br>
>> >> not look like there is bigger progress in G1. For example will we ever<br>
>> >> 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<br>
>> >> be<br>
>> >> good.<br>
>> >><br>
>> >> Having said that CMS is not better in this areas (but people are used<br>
>> >> to<br>
>> >> tune it).<br>
>> >><br>
>> >> And just to be constructive: alternative to prolonging CMS life would<br>
>> >> be<br>
>> >> to heavily invest into G1 by all parties (especially Google and SAP<br>
>> >> 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<br>
>> >> 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<br>
>> >> 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?<br>
>> >> > I<br>
>> >> > think there would be value in having that conversation, and I'd be<br>
>> >> > happy<br>
>> >> > to<br>
>> >> > organize a meeting (unfortunately, I have to miss the JVMLS this<br>
>> >> > 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<br>
>> >> > part<br>
>> >> > of Oracle's build, but it remains community supported. Because it<br>
>> >> > has<br>
>> >> > been<br>
>> >> > on life support for the past few years, the upstream team has shied<br>
>> >> > away<br>
>> >> > from making substantial changes. This could provide it with a jolt<br>
>> >> > 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<br>
>> >> >> > 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<br>
>> >> >> > to<br>
>> >> >> > be at least a possibility that OpenJDK support for CMS might not<br>
>> >> >> > 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<br>
>> >> >> JEP<br>
>> >> >> so, for clarity's sake, here's my take on this. Jon will correct me<br>
>> >> >> 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,<br>
>> >> >> so<br>
>> >> >> they're trying to reduce the amount of time they spend maintaining<br>
>> >> >> CMS.<br>
>> >> >> At the very least, therefore, they will deprecate CMS in Oracle's<br>
>> >> >> 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<br>
>> >> >> as<br>
>> >> >> whether Red Hat ships an AArch64 build of JDK 9 is a decision for<br>
>> >> >> Red<br>
>> >> >> Hat to make. I don't think this is controversial -- there's really<br>
>> >> >> no<br>
>> >> >> need for anyone to spin conspiracy theories about smoke-filled rooms<br>
>> >> >> in<br>
>> >> >> Redwood Shores (but go ahead and do that if it makes you feel<br>
>> >> >> 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<br>
>> >> >> 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<br>
>> >> >> is<br>
>> >> >> removed from the mainline Release Projects but kept alive in a new<br>
>> >> >> 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<br>
>> >> >> is,<br>
>> >> >> "Does anybody outside of Oracle wish to take on the maintenance of<br>
>> >> >> 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>
><br>
><br>
</div></div></blockquote></div><br></div>