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

[Roman Kennke]

Hello all,

This is an update on the proposed patch.

- It is rebased on latest jdk11u-dev, and in particular on the backport of:
https://bugs.openjdk.java.net/browse/JDK-8209686

... which considerably improves C2 shared-code-changes.

- Includes the latest bunch of Shenandoah/jdk11u backports by Aleksey:
https://mail.openjdk.java.net/pipermail/shenandoah-dev/2020-February/011417.html

Full webrev:
http://cr.openjdk.java.net/~rkennke/shenandoah-jdk11u-upstream/webrev.03-all/

Shared-code webrev:
http://cr.openjdk.java.net/~rkennke/shenandoah-jdk11u-upstream/webrev.03-shared/

Please review/test that instead of the previous patches.

Thanks,
Roman

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