[aarch64-port-dev ] RFR: RFR: Bulk integration shenandoah/jdk8u -> aarch64-port/jdk8u-shenandoah 2018-12-13

[Aleksey Shipilev]

On 12/22/18 4:53 PM, Andrew Hughes wrote:
>>> Mostly ok, but for:
>>>
>>> changeset:   10742:c935e0b6b4b2
>>> user:        shade
>>> date:        Thu Oct 25 20:38:21 2018 +0200
>>> summary:     [backport] Cherry-pick JDK-8212673, fix for Node::eqv_uncast
>>>
>>> This doesn't seem to have been requested for OpenJDK 11 upstream, never mind 8u.
>>> Why is it being backported only to shenandoah?
>>
>>
>> Because the orginal issue has been made more or less specifically for
>> Shenandoah:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8212603
>>
>> and JDK-8212673 fixes an issue with the change. IOW, it's Shenandoah
>> specific.
>>
>> Roman
>>
> 
> Ok, but is it harmful to other collectors to have it upstream? I'm trying to
> minimise our divergence where possible.
> 
> 8212603 is not in 8u or shenandoah-8u. Is 8212673 still applicable in its
> absence as a standalone fix?

Yes. 8212673 reverts parts of 8212603, and does the fix more narrowly.

The final code in 11+ is calling to BarrierSet at callnode.cpp, and particular GC choose what to do
with it. In 8u, there is no good GC interface, so we "just" call through Shenandoah-specific
ShenandoahBarrierNode::skip_through_barrier, which is no-op when Shenandoah is disabled. I think
there are other existing places in 8u where the same thing happens.

The final code for 8u does not diverge from upstream much:

https://builds.shipilev.net/patch-openjdk-shenandoah-jdk8-only-shared/latest/src/share/vm/opto/callnode.cpp.sdiff.html

...and there are no changes in node.{c|h}pp from 8212603 left:

https://builds.shipilev.net/patch-openjdk-shenandoah-jdk8-only-shared/latest/src/share/vm/opto/node.cpp.sdiff.html

https://builds.shipilev.net/patch-openjdk-shenandoah-jdk8-only-shared/latest/src/share/vm/opto/node.hpp.sdiff.html

HTHS,
-Aleksey