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

[Aleksey Shipilev]

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. 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?

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