Future of CMS

[Jon Masamitsu]

On 6/16/2016 1:33 PM, Jungwoo Ha wrote:
> I open to any different ways that is reasonable.
> What do you have in mind?

I wanted to look at a specific example because different
solutions would apply to different situations.

Generally, readability is important to us for a change
like this.  Just put yourself in our position.  If you didn't
work with CMS code, why have to look at it.  Some
cases, of course, will be unavoidable.

Jon

>
> On Wed, Jun 15, 2016 at 2:00 PM, Jon Masamitsu 
> <jon.masamitsu at oracle.com <mailto:jon.masamitsu at oracle.com>> wrote:
>
>     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>
>>
>
>
>
>
> -- 
> 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/20160617/5f5722b5/attachment.htm>