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

[Andrew Hughes]

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,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222