[aarch64-port-dev ] RFR: Bulk Shenandoah integration, 2019-09-09

[Aleksey Shipilev]

Hi,

Please review the routine integration of Shenandoah updates to aarch64-port/jdk8u-shenandoah. Since
this involves the cross-repository pull, the webrev is hard to generate without including merge
fluff. Current integration basically picks up everything here:
  https://builds.shipilev.net/patch-openjdk-shenandoah-jdk8/hotspot/

Only hotspot is needed to update. Everything else is in perfect sync already.

Changesets to be pushed:
  https://cr.openjdk.java.net/~shade/shenandoah/merges/aarch64-port-8u-20190909/changesets.txt

Squashed patch to cross-check what is being pushed:
  https://cr.openjdk.java.net/~shade/shenandoah/merges/aarch64-port-8u-20190909/all-diffs.patch

Tour of changes:

*) assembler_x86.(cpp|hpp), macroAssembler_x86.cpp, templateTable_x86_64.cpp removes
jccb/jmpb_if_possible, and returns affected chunks to upstream state.

This code was added for Shenandoah store checking code long time ago, and was never used after
Shenandoah parts were removed. See the current difference against upstream here, we are reverting
some of those:

https://builds.shipilev.net/patch-openjdk-jdk8-aarch64/hotspot/src/cpu/x86/vm/assembler_x86.hpp.sdiff.html

https://builds.shipilev.net/patch-openjdk-jdk8-aarch64/hotspot/src/cpu/x86/vm/assembler_x86.cpp.sdiff.html

https://builds.shipilev.net/patch-openjdk-jdk8-aarch64/hotspot/src/cpu/x86/vm/templateTable_x86_64.cpp.sdiff.html

https://builds.shipilev.net/patch-openjdk-jdk8-aarch64/hotspot/src/cpu/x86/vm/macroAssembler_x86.cpp.sdiff.html

 *) x86_64.ad reverts chunks to upstream state. immU8 was used to match Shenandoah gc-state checks,
and now handled elsewhere. Whitespace changes were the leftovers from previous removals and/or
backports. See the current difference against upstream here, we are removing some of those:
  https://builds.shipilev.net/patch-openjdk-jdk8-aarch64/hotspot/src/cpu/x86/vm/x86_64.ad.sdiff.html

 *) c1_LIR.(cpp|hpp) protects lir_shenandoah_wb, like it does in 11+

 *) shenandoahRootProcessor.(cpp|hpp), shenandoahSynchronizerIterator.(cpp|hpp), synchronizer.cpp,
thread.cpp: removes ShenandoahFastSyncRoots, refactors it a bit, and reverts ObjectSynchronizer to
upstream state.

This one is actually a subtle bugfix disguised as the reversal to upstream state, see:
  https://mail.openjdk.java.net/pipermail/shenandoah-dev/2019-July/010124.html

See the current difference against upstream here, we are reverting some of those chunks:

https://builds.shipilev.net/patch-openjdk-jdk8-aarch64/hotspot/src/share/vm/runtime/synchronizer.cpp.sdiff.html

https://builds.shipilev.net/patch-openjdk-jdk8-aarch64/hotspot/src/share/vm/runtime/synchronizer.hpp.sdiff.html

https://builds.shipilev.net/patch-openjdk-jdk8-aarch64/hotspot/src/share/vm/runtime/thread.cpp.sdiff.html

 *) arguments.cpp: drops UseNUMAInterleaving in Shenandoah-specific initialization block. It is in
shenandoahArguments.cpp in other releases, but 8u is not luxurious enough to have GC-specific
argument handling yet.

 *) bitMap.inline.hpp: since JDK-8211926 landed via backports, this assert should be generic, and
not Shenandoah-specific. This change reverts it to upstream state. See the current difference with
upstream, we are reverting the assert to upstream state:

https://builds.shipilev.net/patch-openjdk-jdk8-aarch64/hotspot/src/share/vm/utilities/bitMap.inline.hpp.sdiff.html

Testing: Linux {x86_64, aarch64} hotspot_gc_shenandoah, regular build and tests on all platforms

-- 
Thanks,
-Aleksey