Future of CMS

[Jon Masamitsu]

Jungwoo,

Could you send an example of something that would
go under INCLUDE_CMS_GC?  We might suggest an
alternative.  Having macros in the sources sometimes
make it harder to read.

Thanks.

Jon

On 06/15/2016 11:29 AM, Jungwoo Ha wrote:
> Sounds reasonable to me.
> CMS uses quite a bit of common code (ParNew, DefNew, CardTable..., JIT 
> for wb)
> 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 <mailto:volker.simonis at gmail.com>> wrote:
>
>     On Tue, Jun 14, 2016 at 11:50 PM, Jungwoo Ha <jwha at google.com
>     <mailto: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 <mailto:jwha at google.com>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20160615/3e12eadd/attachment.htm>