Future of CMS

[Volker Simonis]

On Wed, Jun 15, 2016 at 8:29 PM, Jungwoo Ha <jwha at google.com> 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.

Unfortunately, exclusion from JPRT currently only works on file level.

In general we should really get rid of this restriction at all and I
think this project is another good argument in favor of removing it.

>
>
> On Wed, Jun 15, 2016 at 1:43 AM, Volker Simonis <volker.simonis at gmail.com>
> wrote:
>>
>> 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
>