RFR/RFC: Pick up aarch64-shenandoah-jdk8u222-b02 to sh/jdk8

[Aleksey Shipilev]

Hi,

This is our first ever merge from aarch64-port/jdk8u-shenandoah to sh/jdk8. This picks up
aarch64-shenandoah-jdk8u222-b02 tag and merges it into sh/jdk8.

Changesets (only hotspot, others are trivial):
  http://cr.openjdk.java.net/~shade/shenandoah/merges/jdk8-8u222-b02/changesets.txt

Webrev (only hotspot, others are trivial):
  http://cr.openjdk.java.net/~shade/shenandoah/merges/jdk8-8u222-b02/webrev.01/

Testing: hotspot_gc_shenandoah {fastdebug,release}

Andrew Hughes, we need to agree on process here. The way it is done right now, we are doing this:
 a. Pull aarch64-port/jdk8u-shenandoah -> sh/jdk8, merge
 b. Test it, pile on our backports
 c. Repeat (a)-(b) until Shenandoah is stable
 d. RFR the pull sh/jdk8 -> aarch64-port/jdk8u-shenandoah, tag it appropriately

Since aarch64-port/jdk8u-shenandoah and sh/jdk8 are related now, this allows us to push/pull between
them without any Mercurial voodoo. The caveat there is that the pull at (d) would include a few
local "merge" changesets from (a), are you fine with that? I also prefer not to introduce new
sh/jdk8-specific tags to avoid contaminating aarch64-port/jdk8u-shenandoah with them, so those
merges would be untagged.

You could ask why don't we just push the backports to aarch64-port/jdk8u-shenandoah, but the trouble
is that 8u is a mess GC-interface-wise, and we would like to have sh/jdk8 as additional sandbox to
test for ourselves before integrating. It would be better as we backport more simplifications like
LRB and nofwdptr features into sh/jdk8u, which would get Shenandoah upstream exposure down
significantly. But so far it is what it is.

-- 
Thanks,
-Aleksey