RFR (11u, XXL): Upstream/backport Shenandoah to JDK11u
Ron Pressler
ron.pressler at oracle.com
Thu Jul 2 23:18:54 UTC 2020
Feature releases were always outdated quickly even back when they were
called “limited update” releases. We can’t compare them to the old major
releases because they are not the same at all. When 8u20 came out there
were >100 developers working on 8u40 and zero people working on 8. Now,
when 11 comes out, hundreds of people work on 12, and a few stay with 11.
Comparing either 11u or 15 to a major release like 8 doesn’t make sense, each
for a different reason. The new model is just incomparable to the old one.
— Ron
On 2 July 2020 at 21:35:56, Lindenmaier, Goetz (goetz.lindenmaier at sap.com) wrote:
Hi Ron
> > We even delivered Java 4-7 with hotspot of 8,
> > without breaking our huge software stack
> > ...
> 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.
We were roughly 15 people working on this.
> > 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.
In the new release model, the feature releases are outdated before
anybody started to do anything. Lots of software still runs on 5, 6 etc!
8 was extended until 2027 because people don't want to move.
But yes, for an app that is released every two weeks to the cloud,
and built on 11 or more recent, according to modern software
architecture principles, this works, and actually happens.
I just wanted to say that for us it was a success story to
bring compressed oops, metaspace etc. to SAP JVM 4-8,
and it worked, and it didn't cause tremendous support, it
rather reduced the support.
Best regards,
Goetz.
> > 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
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> >
More information about the jdk-updates-dev
mailing list