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

[Aleksey Shipilev]

Ping Andrew Hughes.

On 5/20/19 12:26 PM, Aleksey Shipilev wrote:
> 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