[aarch64-port-dev ] RFR/RFC: Shenandoah integration 2021-03-11

[Aleksey Shipilev]

On 3/11/21 6:22 PM, Andrew Hughes wrote:
>> There is no merge changeset, as shenandoah/jdk8 forest is clean downstream
>> of integration repository. I am tagging the whole thing as
>> aarch64-shenandoah-jdk8u292-b05-shenandoah-merge-2021-03-11.
> 
> Sounds good. The webrev does suggest there are merge revisions though:
> 
> https://cr.openjdk.java.net/~shade/shenandoah/merges/aarch64-port-8u-20210311/webrev.01/
> 
> e.g. "rev 12213 : Merge"

Yes, these are merges during the pickups _from_ aarch64-port/jdk8u-shenandoah to shenandoah/jdk8.

>> Testing: hotspot_gc_shenandoah; it also runs pretty stably in our CIs, and
>> we have no user bugreports from our 8u nightlies
> 
> Was it tested without INCLUDE_ALL_GCS defined?

Yes, our (well, my) CI implicitly tests this with when building Minimal VM. It does it for all 
repositories, including aarch64-port/jdk8u-shenandoah and shenandoah/jdk8, so neither side is broken 
at the moment :)

> My only concern is the backporting of 8202976: "Add C1 lea patching support for x86"

Yeah, alas we needed it for Shenandoah to do self-fixing barriers.

> It looks like the changes will have no effect when Shenandoah is disabled at runtime,
> though the code changes differ between using INCLUDE_ALL_GCS as well in
> c1_LIRAssembler_aarch64.cpp but not in c1_LIRAssembler_x86.cpp (difficult to do
> so there with the structure of the code).
> 
> At the very least, this will produce some unused variable warnings, but that is true
> of JDK-8202976 in 11u too.

It should not produce unused warnings, as UseShenandoahGC would always be available.

IIRC, Andrew Haley lifted the prior policy that every Shenandoah block should always be protected by 
INCLUDE_ALL_GCS. We now "only" use it to protect the code blocks that touch Shenandoah symbols, 
which might not be available in some configs. c1_LIRAssembler_x86.cpp is not such a block.

Anything else you want answered / done?

-- 
Thanks,
-Aleksey