[aarch64-port-dev ] [RFR] 8u152 Upstream Sync

[Andrew Hughes]

On 23 January 2018 at 19:35, Aleksey Shipilev <shade at redhat.com> wrote:
> On 01/23/2018 07:40 PM, Andrew Hughes wrote:
>> For the Shenandoah devs:
>>
>> The Shenandoah merge (aarch64-shenandoah-jdk8u152-b16) was non-trivial on
>> this occasion, so I've included it here:
>>
>> http://cr.openjdk.java.net/~andrew/aarch64-8/u152/hotspot/shenandoah.changeset
>
> It is really, really hard to spot what are the changes coming from upstream, and what have you
> changed during the merge.

I try to change next to nothing during the merge for this reason. I've
had no end of
trouble in the past with unexplained upstream changes being tracked down to part
of a merge changeset, with no other explanation.

But this seriously does not compute:
>
> $ wget http://cr.openjdk.java.net/~andrew/aarch64-8/u152/hotspot/shenandoah.changeset -q -O - |
> diffstat | tail -n 1
>  124 files changed, 3007 insertions(+), 773 deletions(-)
>
> $ wget http://cr.openjdk.java.net/~andrew/aarch64-8/u152/hotspot/hotspot.changeset -q -O - |
> diffstat | tail -n 1
>  198 files changed, 11964 insertions(+), 3966 deletions(-)
>
> $ wget http://cr.openjdk.java.net/~andrew/aarch64-8/u152/hotspot/merge.changeset -q -O - | diffstat
> | tail -n 1
>  1 file changed, 1 insertion(+)
>
> Is this because aarch64-port/shenandoah-8u is ahead of aarch64-port/jdk8u?

It looks like the merge.changeset for the HotSpot repository was wrong
because a fix was pushed
upstream after the merge began. The script I use to generate them just
takes the parent of the tip
as being the merge, and this was broken when another change was pulled
in from upstream.
I've fixed it now by using the parent of the tag instead.

The updated file has been uploaded and the correct diffstat for
merge.changeset is:

 132 files changed, 3148 insertions(+), 786 deletions(-)

Which fits much closer to the Shenandoah merge changeset.

Shenandoah does appear to have pulled in some u152 fixes early, which
explains the slight
difference.

>
> Things like these are 100% regressions for Shenandoah:
>
> -        if (! oopDesc::equals(saved, result()))
> +        if (saved != result())
>
> ...
>
> -        oop saved = MethodHandles::init_method_MemberName(result, info);
> -        if (! oopDesc::equals(saved, result()))
> +        // Since this is going through the methods to create MemberNames, don't search
> +        // for matching methods already in the table
> +        oop saved = MethodHandles::init_method_MemberName(result, info, /*intern*/false);
> +        if (saved != result())
>
> Basically, removing any oopDesc::equals, oopDesc::unsafe_equals, read_barrier, write_barrier are
> regressing Shenandoah. The converse is true for *new* oop comparisons (except comparisons with
> NULL), like this:
>
> +bool java_lang_invoke_MemberName::equals(oop mn1, oop mn2) {
> +  if (mn1 == mn2) {
> +     return true;
> +  }
> +  return (vmtarget(mn1) == vmtarget(mn2) && flags(mn1) == flags(mn2) &&
> +          vmindex(mn1) == vmindex(mn2) &&
> +          clazz(mn1) == clazz(mn2));
> +}
> +
>
> These three are the only problems I was able to spot in the patch. Running simple applications with
> -XX:+VerifyStrictOopOperations would help to diagnose the rest. Or, run hotspot_gc_shenandoah with
> "make test TEST=hotspot_gc_shenandoah".
>
> -Aleksey
>

Sounds like we need a follow-on Shenandoah port of:

changeset:   9844:575f637864df
user:        kevinw
date:        Fri Feb 24 06:48:48 2017 -0800
summary:     8162795: [REDO] MemberNameTable doesn't purge stale entries

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