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

[Roman Kennke]

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