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

[Roman Kennke]

>> 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
>>
> 
> Thanks. It's still not clear to me why this couldn't go into upstream
> 8u & 11u though.

I don't think that the fix is needed in 11 or 8u upstream, because
JDK-8212603 isn't there?

Can I push the Shenandoah integration?

Roman