<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Jungwoo,<br>
<br>
Could you send an example of something that would<br>
go under INCLUDE_CMS_GC? We might suggest an<br>
alternative. Having macros in the sources sometimes<br>
make it harder to read.<br>
<br>
Thanks.<br>
<br>
Jon<br>
<br>
<div class="moz-cite-prefix">On 06/15/2016 11:29 AM, Jungwoo Ha
wrote:<br>
</div>
<blockquote
cite="mid:CA+n_jhhm2OrDsFvMgdYZsvyekP8Z-++gj-W_4kQo9LKP+fH0Ag@mail.gmail.com"
type="cite">
<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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:jwha@google.com" target="_blank">jwha@google.com</a></span><br>
</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>