RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u

Mon Jun 29 18:29:55 UTC 2020

Hi,

We as SAP would not object against this change.
Several reasons:

1. I had a look at the shared changes.
    If this is all, it is very unlikely that this change breaks 
    the current configuration of jdk11u.  Nice job of bringing
    this to 11.

2. In the past, the VMs got a lot of new features 
    in hotspot every half year. This worked, too.
    We even delivered Java 4-7 with hotspot of 8,
    without breaking our huge software stack. Yes,
    there were errors, but much more were solved
    by this approach.

3. My experience is that it is much harder to 
    move software to new Java versions than to 
    bring a feature to an older VM.  We have lots of software
    running where the development teams are almost
    gone.  But the maintainers of the VM on SAP side, 
    and the operators of the software at customer side,
    are still there.  These are the ones that have to deal
    with the bugs introduced by the downport.  These are also
    the ones whose problems are solved by a better GC.
    The application developers would have to deal with 
    bringing the software to new Java versions, but they
    are no more available. 

Naturally, this does not hold for features that
break compatibility of the libraries or the language.

But please configure the build so that Shenandoah is
not built per default.  See make/autoconf/hotspot.m4.

Shenandoah could be enabled later, but at first I would 
prefer if it is not compiled into everybodys binary.

Best regards,
  Goetz.

PS: I hope this mail gets delivered to the list, a row 
of my mails today didn't make it there.

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On Behalf
> Of Roman Kennke
> Sent: Thursday, June 25, 2020 1:16 PM
> To: jdk-updates-dev at openjdk.java.net
> Subject: Re: RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u
> 
> I would like to revive this RFR, I believe we haven't come to a
> conclusion yet. I still think it would be very useful to have the
> Shenandoah GC included in jdk11u upstream. I have heard from several
> vendors who would like to ship Shenandoah, but maintaining the rather
> huge Shenandoah backport patch is an absolute no-go.
> 
> This is an updated patch that includes numerous bugfixes and
> improvements in Shenandoah. It is what Red Hat is going to ship in
> their 11.0.8 release.
> 
> Full webrev:
> https://cr.openjdk.java.net/~rkennke/shenandoah-jdk11u-
> upstream/webrev.04-all/
> 
> Webrev only for shared-code changes:
> https://cr.openjdk.java.net/~rkennke/shenandoah-jdk11u-
> upstream/webrev.04-shared/
> 
> Please let me know what you think.
> 
> Roman
> 
> > On Fri, 2020-01-17 at 18:05 +0100, Roman Kennke wrote:
> > Hello,
> >
> > The Shenandoah GC has been integrated into jdk12 a little over a year
> > ago:
> >
> > http://hg.openjdk.java.net/jdk/jdk/rev/9c18c9d839d3
> >
> > The Shenandoah team has been maintaining the Shenandoah-enabled
> > jdk11u
> > downstream repository since the inception of jdk11 under:
> >
> > http://hg.openjdk.java.net/shenandoah/jdk11
> >
> > In order to make it more useful and accessible for users, we would
> > like
> > to make it available in upstream jdk11u. The Shenandoah team at Red
> > Hat
> > intends to maintain it the same way it had been maintained in
> > shenandoah/jdk11, in the course of regular jdk11u maintenance Red Hat
> > already does.
> >
> > Thanks to recent changes in Shenandoah over the last year, we are now
> > able to fit the GC interface in jdk11 almost exactly. There are a few
> > exceptions though. We tried to follow the following pattern for all
> > shared-code changes where it made sense:
> >
> > #if INCLUDE_SHENANDOAH_GC
> >   if (UseShenandoahGC) {
> >     ...
> >   }
> > #endif
> >
> > This ensures that the Shenandoah-specific changes are cut out of the
> > build when building without Shenandoah, and avoid those code paths at
> > runtime when running without Shenandoah.
> >
> > Also, there are a few places where this was not possible or where it
> > didn't seem feasible, but we tried to keep them few and obvious.
> > Whenever this is the case, we are mirroring as close as possible what
> > we
> > have in jdk/jdk.
> >
> > Architecture-wise, Shenandoah runs on x86_64, aarch64, x86_32. Other
> > architectures still build fine, and Shenandoah gets automatically
> > disabled during configure if not supported. OS-wise, Shenandoah runs
> > on
> > Linux, Windows, and is known to run on MacOS X and Solaris too.
> >
> > I wasn't sure which form this should take. I decided to start with
> > the
> > easiest possible form this could take: a simple patch/webrev and an
> > RFR.
> > Let me know if you need a JIRA issue or any other formalities to
> > track that.
> >
> > Full webrev:
> > https://cr.openjdk.java.net/~rkennke/shenandoah-jdk11u-
> upstream/webrev.02-all/
> >
> > Webrev only for shared-code changes:
> > https://cr.openjdk.java.net/~rkennke/shenandoah-jdk11u-
> upstream/webrev.02-shared/
> >
> > The webrevs are based on and depend on the arraycopy patch proposed
> > for
> > review here:
> >
> > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-
> January/002396.html
> >
> > Testing:
> > The code has been tested many many times, continuously while
> > maintaining
> > it. It has also served as the basis for RPMs and shipped to
> > customers.
> > We are running all sorts of tests of the hotspot/jtreg testsuite, in
> > particular hotspot_gc_shenandoah, CTW tests, the regular tier* tests,
> > several popular benchmarks (specjvm, specjbb on a regular basis), on
> > a
> > nightly basis.
> >
> > Please let me know what you think.
> >
> > Thanks,
> > Roman
> >
> >
> >
> >
> >
> >
> >