Future of CMS

[Volker Simonis]

On Tue, Jun 14, 2016 at 11:50 PM, Jungwoo Ha <jwha at google.com> wrote:
>>
>> But seriously: SAP is supporting CMS and will probably do so for quite a
>> long time (simply because we do support old Java releases for a very long
>> time).
>>
>>
>> Completely removing CMS from the HotSpot code base may increase these
>> support costs considerably for us.
>>
>> Do you plan to really delete the sources from the repos or do you only
>> plan to disable it at build time?
>>
>>
>> I just don't know how this is going to play out.  I expect that the
>> OpenJDK community
>> will want the sources to stay.  In such a case Oracle would want them
>> segregated sufficiently
>> that we don't build the the sources.
>>
>> I think only disable it at build time would make it easier for us and
>> others to still support it in the future. But in that case we really have to
>> come up with a better development model which would allow external
>> developers to directly push CMS changes (much like ppc64 or aarch64
>> changes). Everything else would be a real PITA.
>>
>>
>> I think some model like ppc64/aarch64 would be a good way to go.   That
>> would be a
>> nice side effect of this change.  You know better than I on how to get
>> there.
>
>
> We also need to support CMS perhaps for a long time. I like the idea of
> segregating it, and have more external developers contribute to it.
> Is there any document or can anyone explain to me how ppc64/arch64 works?
> In such case, who is responsible for code review, building, testing, release
> and so on?

There's nothing special in the way the ppc64/arch64 projects/ports
work. They are integral part of hotspot/openjdk and contributing to
them is regulated by the very same rules.

The only thing that we've manged to somehow mitigate for ppc64/arch64
is the pain that external (i.e. non-Oracle) committers are still not
able to directly push to the hotspot repositories because of Oracles
inability/unwillingness to open up their infamous JPRT pre-integration
test system. So as an exception to this restriction, we are now
allowed to push changes directly, if they only touch files in
hotspot/src/cpu/{ppc,aarch64}. This helps a little bit but still not
always, because many changes still touch shared code (e.g. if they
come with a regression test which is in hotspot/test we already need
an Oracle sponsor even if we're committers and the change is fully
reviewed).

Building and testing the ports is the exclusive duty of the
corresponding projects. So for example we at SAP have nightly builds
of all relevant OpenJDK repositories on our porting platforms and I'm
pretty sure Red Hat has the same for aarch64.

Regarding CMS, I think the idea is that the CMS sources should be
separated into their own directory with the same relaxed checkin rules
like the ones for ppc64/arch64. But again this would only help a
little bit, because there will still remain quite some supporting CMS
code in shared places (e.g. runtime, compilers, etc..).

Also, building CMS will probably be controlled by a
build-time/configure option (i.e. --use-cms) which will be switched
off by default. So it would be our duty to build with these option
turned on and test the resulting builds.

Regards,
Volker


>