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

[Roman Kennke]

Hi there,

I still couldn't integrate this into the repo. Last time we discussed, 
the plan was to integrate after 8u202 landed. It doesn't seem to be 
there yet:

http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/

When would be a good time to finally push this? I'm already working on 
the next 3 months worth of backports ;-)

Roman

> On Mon, 7 Jan 2019 at 08:36, Aleksey Shipilev <shade at redhat.com> wrote:
>>
>> On 1/7/19 6:35 AM, Andrew Hughes wrote:
>>> On Fri, 28 Dec 2018 at 21:13, Roman Kennke <rkennke at redhat.com> wrote:
>>>> 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?
>>>
>>> I get that, but it's not what I'm asking.
>>>
>>> My question is: would it be harmful to push 8212603 to upstream 8u/11u to reduce
>>> our divergence from upstream?
>>
>> No. JDK-8212603 is also not in upstream, it was reverted by JDK-8212673.
>>
>>> I would prefer that, if possible, to only carrying the fix in the
>>> shenandoah tree.
>>
>> ...and without GC interface (which was introduced in 10 and 11), JDK-8212673 would unavoidably be
>> GC-specific, and mentioning the concrete GC.
>>
>> You'll need to "upstream" things like:
>>
>> -       if (lock->obj_node()->eqv_uncast(unlock->obj_node()) &&
>> +       Node* lock_obj = ShenandoahBarrierNode::skip_through_barrier(lock->obj_node());
>> +       Node* unlock_obj = ShenandoahBarrierNode::skip_through_barrier(unlock->obj_node());
>> +       if (lock_obj->eqv_uncast(unlock_obj) &&
>>
>> Therefore, there is no added benefit to push it through upstream first, and I cannot even see how
>> that would be possible given there is no Shenandoah in upstream 8u.
>>
> 
> Right, so although it's using the upstream bug ID, the backport to
> shenandoah-8u is effectively
> Shenandoah-specific?
> If so, then that's fine by me. I just don't want us to diverge where
> we don't have to.
> 
>> -Aleksey
>>
> 
> Thanks,
>