Future of CMS

Jungwoo Ha jwha at google.com
Wed Jun 15 18:29:26 UTC 2016

Sounds reasonable to me.
CMS uses quite a bit of common code (ParNew, DefNew, CardTable..., JIT for
If we have the build flag, that means we have a macro (e.g. INCLUDE_CMS_GC).
It would be great if the common part code is wrapped with the macro,
external contributor can submit without the pre-integration test.

On Wed, Jun 15, 2016 at 1:43 AM, Volker Simonis <volker.simonis at gmail.com>

> 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
> >

Jungwoo Ha | Java Platform Team | jwha at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20160615/47e2f982/attachment.htm>

More information about the hotspot-gc-dev mailing list