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

[Aleksey Shipilev]

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.

-Aleksey