<div dir="ltr">Sounds reasonable to me. <div>CMS uses quite a bit of common code (ParNew, DefNew, CardTable..., JIT for wb)<br><div><div>If we have the build flag, that means we have a macro (e.g. INCLUDE_CMS_GC).</div></div></div><div>It would be great if the common part code is wrapped with the macro, external contributor can submit without the pre-integration test.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 15, 2016 at 1:43 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"><div class="HOEnZb"><div class="h5">On Tue, Jun 14, 2016 at 11:50 PM, Jungwoo Ha <<a href="mailto:jwha@google.com">jwha@google.com</a>> wrote:<br>
>><br>
>> But seriously: SAP is supporting CMS and will probably do so for quite a<br>
>> long time (simply because we do support old Java releases for a very long<br>
>> time).<br>
>><br>
>><br>
>> Completely removing CMS from the HotSpot code base may increase these<br>
>> support costs considerably for us.<br>
>><br>
>> Do you plan to really delete the sources from the repos or do you only<br>
>> plan to disable it at build time?<br>
>><br>
>><br>
>> I just don't know how this is going to play out. I expect that the<br>
>> OpenJDK community<br>
>> will want the sources to stay. In such a case Oracle would want them<br>
>> segregated sufficiently<br>
>> that we don't build the the sources.<br>
>><br>
>> I think only disable it at build time would make it easier for us and<br>
>> others to still support it in the future. But in that case we really have to<br>
>> come up with a better development model which would allow external<br>
>> developers to directly push CMS changes (much like ppc64 or aarch64<br>
>> changes). Everything else would be a real PITA.<br>
>><br>
>><br>
>> I think some model like ppc64/aarch64 would be a good way to go.  That<br>
>> would be a<br>
>> nice side effect of this change. You know better than I on how to get<br>
>> there.<br>
><br>
><br>
> We also need to support CMS perhaps for a long time. I like the idea of<br>
> segregating it, and have more external developers contribute to it.<br>
> Is there any document or can anyone explain to me how ppc64/arch64 works?<br>
> In such case, who is responsible for code review, building, testing, release<br>
> and so on?<br>
<br>
</div></div>There's nothing special in the way the ppc64/arch64 projects/ports<br>
work. They are integral part of hotspot/openjdk and contributing to<br>
them is regulated by the very same rules.<br>
<br>
The only thing that we've manged to somehow mitigate for ppc64/arch64<br>
is the pain that external (i.e. non-Oracle) committers are still not<br>
able to directly push to the hotspot repositories because of Oracles<br>
inability/unwillingness to open up their infamous JPRT pre-integration<br>
test system. So as an exception to this restriction, we are now<br>
allowed to push changes directly, if they only touch files in<br>
hotspot/src/cpu/{ppc,aarch64}. This helps a little bit but still not<br>
always, because many changes still touch shared code (e.g. if they<br>
come with a regression test which is in hotspot/test we already need<br>
an Oracle sponsor even if we're committers and the change is fully<br>
reviewed).<br>
<br>
Building and testing the ports is the exclusive duty of the<br>
corresponding projects. So for example we at SAP have nightly builds<br>
of all relevant OpenJDK repositories on our porting platforms and I'm<br>
pretty sure Red Hat has the same for aarch64.<br>
<br>
Regarding CMS, I think the idea is that the CMS sources should be<br>
separated into their own directory with the same relaxed checkin rules<br>
like the ones for ppc64/arch64. But again this would only help a<br>
little bit, because there will still remain quite some supporting CMS<br>
code in shared places (e.g. runtime, compilers, etc..).<br>
<br>
Also, building CMS will probably be controlled by a<br>
build-time/configure option (i.e. --use-cms) which will be switched<br>
off by default. So it would be our duty to build with these option<br>
turned on and test the resulting builds.<br>
<br>
Regards,<br>
Volker<br>
<br>
<br>
><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><span style="font-size:12.8000001907349px">Jungwoo Ha | Java Platform Team | <a href="mailto:jwha@google.com" target="_blank">jwha@google.com</a></span><br></div><div><br></div></div></div>
</div>