<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Jeremy,<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Kind regards,</div><div class="">Kirk Pepperdine</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 8, 2016, at 8:46 PM, Jeremy Manson <<a href="mailto:jeremymanson@google.com" class="">jeremymanson@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hey folks,<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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).<br class=""></div><div class=""><br class=""></div><div class=""><div class="">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.</div></div><div class=""><br class=""></div><div class="">Any takers?</div><div class=""><br class=""></div><div class="">Jeremy</div><div class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Jul 1, 2016 at 2:08 PM, <span dir="ltr" class=""><<a href="mailto:mark.reinhold@oracle.com" target="_blank" class="">mark.reinhold@oracle.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2016/7/1 1:50:41 -0700, <a href="mailto:aph@redhat.com" class="">aph@redhat.com</a>:<br class="">
<span class="">> On 30/06/16 22:35, <a href="mailto:mark.reinhold@oracle.com" class="">mark.reinhold@oracle.com</a> wrote:<br class="">
>> New JEP Candidate: <a href="http://openjdk.java.net/jeps/291" rel="noreferrer" target="_blank" class="">http://openjdk.java.net/jeps/291</a><br class="">
><br class="">
> I think that there is likely to be a fair amount of push-back against<br class="">
> this one. I understand that the GC team has to be responsible for<br class="">
> this decision, given that they have to support it. But there has to<br class="">
> be at least a possibility that OpenJDK support for CMS might not be<br class="">
> ended, and Oracle is not necessarily the only company involved in<br class="">
> this.<br class="">
<br class="">
</span>I think that's well understood.<br class="">
<br class="">
There are limits to what can be expressed within the structure of a JEP<br class="">
so, for clarity's sake, here's my take on this. Jon will correct me if<br class="">
I've got any of it wrong, I'm sure.<br class="">
<br class="">
Oracle's GC team is intensely focused on improving the G1 collector, so<br class="">
they're trying to reduce the amount of time they spend maintaining CMS.<br class="">
At the very least, therefore, they will deprecate CMS in Oracle's JDK 9<br class="">
product builds and then, most likely but depending upon end-user and<br class="">
customer feedback, remove it entirely from Oracle's JDK 10 builds.<br class="">
<br class="">
Whether and when this happens is a decision for Oracle to make, just as<br class="">
whether Red Hat ships an AArch64 build of JDK 9 is a decision for Red<br class="">
Hat to make. I don't think this is controversial -- there's really no<br class="">
need for anyone to spin conspiracy theories about smoke-filled rooms in<br class="">
Redwood Shores (but go ahead and do that if it makes you feel better).<br class="">
<br class="">
The fate of the CMS GC code itself in any particular OpenJDK Release<br class="">
Project, or in any other OpenJDK Project for that matter, is a different<br class="">
question, about which JEP 291 was intended to prompt a wider discussion,<br class="">
as indeed it has.<br class="">
<br class="">
If a set of credible developers expresses a clear desire to maintain CMS<br class="">
after JDK 9 then all of us who work on this code base, regardless of<br class="">
employer, will find a way for that to happen. Maybe the CMS code stays<br class="">
in JDK 9 and later Release Projects but is #ifdef'd out, or maybe it<br class="">
stays but the common GC interface is refactored so that other collectors<br class="">
(not just G1) can evolve more independently, or maybe the CMS code is<br class="">
removed from the mainline Release Projects but kept alive in a new side<br class="">
Project. Exactly what happens depends mostly, I think, on who shows up.<br class="">
<br class="">
To put it another way, the question that JEP 291 is trying to ask is,<br class="">
"Does anybody outside of Oracle wish to take on the maintenance of CMS<br class="">
after JDK 9? If so, then let's talk."<br class="">
<br class="">
Any takers?<br class="">
<span class="HOEnZb"><font color="#888888" class=""><br class="">
- Mark<br class="">
</font></span></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></div></body></html>