[RFR] [8u] 8u222-b02 Upstream Sync

[Aleksey Shipilev]

On 5/14/19 4:55 PM, Aleksey Shipilev wrote:
> hotspot:
> 
> *) sharedRuntime_aarch64.cpp, templateInterpreter_aarch64.cpp, macroAssembler_x86.cpp,
> jniHandles.cpp: new G1 blocks have to handle Shenandoah too. Luckily, we have this done in sh/jdk9
> (archived), and it could be just picked up from there:
> 
> http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/file/37b802a7a71b/src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp#l2067
> http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/file/37b802a7a71b/src/cpu/aarch64/vm/templateInterpreterGenerator_aarch64.cpp#l1419
> http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/file/37b802a7a71b/src/cpu/x86/vm/macroAssembler_x86.cpp#l5272
> http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/file/37b802a7a71b/src/share/vm/runtime/jniHandles.cpp#l118
> 
> Otherwise looks okay.

I now remember another thing. The absence of Shenandoah additions in those blocks probably do not
crash the VM yet, because we have the Shenandoah-specific workaround for it:
  http://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/119e9a5b24d5
  http://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/d305c31da9f5

Merge is not the proper place to remove that workaround. Maybe we just push this merge verbatim, and
then we would do downstream work to remove the workaround and fix the issue properly with the
changes above, then integrate it back wholesale.

-Aleksey