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

Wed Jul 1 16:09:35 UTC 2020

Without expressing an opinion on this particular issue, I’d
just like to respond to two points you made:

On 29 June 2020 at 19:32:31, Lindenmaier, Goetz (goetz.lindenmaier at sap.com(mailto:goetz.lindenmaier at sap.com)) wrote:

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

That was when the number of people working on the current JDK with
the new VM features was >10x the number of people working on
Updates today. It’s hard to compare the old model wit the new.

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

Again, this should not be the case with the *new* release model
unless 1. the application suffers from severe technical debt and
relies on deprectated/unmaintained/internal code or 2. something 
is wrong or unusual about the new release. In other words, this 
shouldn’t be the case unless there is something wrong with your 
app or with the JDK. 

Under the new release model, reasonably well-maintained applications 
should normally take very little effort to update to a new feature
release.

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