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

[Roman Kennke]

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