February 2016 - aarch64-port-dev

[PATCH] [jdk8u] Remove unused template which breaks builds with GCC 6
by Andrew Hughes 15 May '16

15 May '16

Webrev: http://cr.openjdk.java.net/~andrew/aarch64-8/gcc6/webrev.01/ The min template: template <class T> static const T& min (const T& a, const T& b) causes the build to fail with GCC 6 [0], where the default C++ standard (-std=gnu++98) has to be explicitly specified, as the default has changed. /builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.72-5.b15.fc24.aarch64/openjdk/hotspot/src/share/vm/utilities/globalDefinitions.hpp:1113:18: warning: variable templates only available with -std=c++14 or -std=gnu++14 #define min(a,b) Do_not_use_min_use_MIN2_instead ^ /builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.72-5.b15.fc24.aarch64/openjdk/hotspot/src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp:197:36: note: in expansion of macro 'min' template <class T> static const T& min (const T& a, const T& b) { ^~~ /builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.72-5.b15.fc24.aarch64/openjdk/hotspot/src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp:198:3: error: expected ';' before 'return' return (a > b) ? b : a; ^~~~~~ /builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.72-5.b15.fc24.aarch64/openjdk/hotspot/src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp:199:1: error: expected declaration before '}' token } ^ The template appears to be unused and removing it allows the build to succeed with GCC 6. Ok to push? [0] https://bugzilla.redhat.com/show_bug.cgi?id=1307224#c1 -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222

3 9

Freeze aarch64/jdk8
by Andrew Haley 08 Apr '16

08 Apr '16

The jdk8 development tree at aarch64/jdk8 has been in use for some time. I don't think we need it any more. aarch64/jdk8u tracks upstream jdk8u far more closely: it differs from upstream only in the minimum number of places needed to get AArch64 to work. I'm proposing to close aarch64/jdk8 to all updates. aarch64/jdk8u will be used for all commits. jdk8 is interesting from a historical point of view, so it will be made read only. The rules for committing to aarch64/jdk8u are: 1. All non-AArch64-specific patches come from jdk8u. If you want to change anything non-AArch64 submit it to jdk8u. 2. All AArch64-specific patches, if they are relevant to jdk9, must be submitted there first and back-ported to jdk8u. Andrew.

4 24

arraycopy optimisations on aarch64
by Edward Nevill 08 Mar '16

08 Mar '16

Hi, There have been a number of ongoing efforts at optimising array copy recently. Rather than have multiple webrevs and multiple JIRA issues I would like to collect all the efforts under a single JIRA issue. I have created the following JIRA issue for all work relating to optimising array copy. https://bugs.openjdk.java.net/browse/JDK-8150082 We can then review all the array copy optimisation proposals on the aarch64-port-dev mailing list rather than cc'ing the whole of hotspot-compiler-dev with every intricate detail of array copys on aarch64. Once we have a complete version of array copy code we are happy with I can submit a single CR for review. All contributions will be acknowledged in the "Contributed-by" section. To further muddy the waters I have two patches I would like to forward for your discussion. 1) http://cr.openjdk.java.net/~enevill/memopts/small.patch This improves the performance of copying small (0 to 80 bytes) arrays. The copy code is inlined (rather than calling out to copy_longs). The copy forwards and copy backwards case is identical because the small copy code reads all data into registers before writing any. Thankfully aarch64 has plenty of registers. The rationale for choosing 80 as the limit is that it provides a guarantee than copy_longs is always called with at least 64 bytes, even after worst case alignment fixup. This means the small case code in copy_longs can be deleted (I have put an assert in copy longs to check it is never called with < 64 bytes). 2) http://cr.openjdk.java.net/~enevill/memopts/simd.patch This uses SIMD ldp/stp Qx, Qy instructions instead of scalar ldp/stp instructions, thereby loading/storing 32 bytes at a time instead of 16. It also extends the small copy code to copy 0-96 instead of 0-80 (because 80 is not divisible by 32). This improves performance on some micro-arches and not on others so I have provided a -XX:+UseSIMDForMemoryOps switch which defaults to false (we could look at enabling this by default for micro-arches where we know SIMD is better). I have prepared a set of performance measurements on memory copies between 0 & 96 bytes in steps of 1 (which shows the effect of the small copy optimisations) and also between 0 & 1024 in steps of 16. I have prepared these for 3 different micro-arches. The results are at http://cr.openjdk.java.net/~enevill/memopts/twoopts.pdf In these charts the blue 'original' line is the jdk9 tip as of earlier today. The red 'small copy' line is after application of the small copy patch above. The yellow 'SIMD' line is after the cumulative application of the small copy patch and the simd patch. The charts show time taken so smaller is better. I have normalised the charts by varying the number of iteration so all results are in the 0-1200 range. Because the number of iterations was different for each micro-arch no information should be inferred as to the relative performance of different micro-arches. The charts should only be used to compare the performance before and after application of the above patches. All the best, Ed.

2 3

RFR: 8150394: aarch64: add support for 8.1 LSE CAS instructions
by Edward Nevill 08 Mar '16

08 Mar '16

Hi, Please review the following webrev http://cr.openjdk.java.net/~enevill/8150394/webrev.0/ This adds support for the CAS instructions in armv8.1. The use of the instructions is enabled/disabled by the use of -XX:+/-UseLSE. This is enabled automatically if detected in the hwcap. If UseLSE is enabled on a CPU which does not support these instructions a warning is issued but the instructions are enabled in any case. This is to allow use of the LSE extensions on 8.1 systems which are running older kernels. Tested before and after with jcstress (default mode). In both cases there was 1 failure which is due to a missing Unsafe method and always occurs with jdk9. Thanks for the review, Ed.

3 10

RFR: 8150229: aarch64: c2 fix pipeline class for several instructions.
by Felix Yang 01 Mar '16

01 Mar '16

Hi, Please review the following webrev: http://cr.openjdk.java.net/~fyang/8150229/webrev.00/ Jira issue: *https://bugs.openjdk.java.net/browse/JDK-8150229 <https://bugs.openjdk.java.net/browse/JDK-8150229>* The pipeline class for some instructions is not set correctly. An example: instruct MoveF2I_reg_reg(iRegINoSp dst, vRegF src) %{ match(Set dst (MoveF2I src)); effect(DEF dst, USE src); ins_cost(INSN_COST); format %{ "fmovs $dst, $src\t# MoveF2I_reg_reg" %} ins_encode %{ __ fmovs($dst$$Register, as_FloatRegister($src$$reg)); %} ins_pipe(pipe_class_memory); => Should be "fp_f2i" %} Patch fixes this issue. Tested with jtreg hotspot. Please help commit this patch if it's OK. Thanks, Felix.

3 2

RFR: AArch64 backport to Icedtea7 of 8146709
by Andrew Dinn 29 Feb '16

29 Feb '16

I have backported the patch for 8146709 (Incorrect use of ADRP for byte_map_base) from aarch64/jdk8u to icedtea7-forest. Here's the webrev: http://cr.openjdk.java.net/~adinn/8146709/webrev.00/ This appears to be the cause of the problem running specjvm referred to in bugzilla 1310061 https://bugzilla.redhat.com/show_bug.cgi?id=1310061 Before the patch I saw the error described in the BZ.After the patch it no longer occurs. The patched code passes basic smoke tests. Can I get an ok from someone else before I push this? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (US), Michael O'Neill (Ireland), Paul Argiry (US)

2 2

hg: aarch64-port/jdk8u/nashorn: Added tag aarch64-jdk8u72-b16 for changeset 8eb47ddad851
by gnu.andrew＠redhat.com 29 Feb '16

29 Feb '16

Changeset: af05959dd44b Author: andrew Date: 2016-02-29 06:45 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/nashorn/rev/af05959dd44b Added tag aarch64-jdk8u72-b16 for changeset 8eb47ddad851 ! .hgtags

1 0

hg: aarch64-port/jdk8u/jdk: Added tag aarch64-jdk8u72-b16 for changeset b39ade4fa554
by gnu.andrew＠redhat.com 29 Feb '16

29 Feb '16

Changeset: 9331bfc2d798 Author: andrew Date: 2016-02-29 06:45 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/9331bfc2d798 Added tag aarch64-jdk8u72-b16 for changeset b39ade4fa554 ! .hgtags

1 0

hg: aarch64-port/jdk8u/hotspot: Added tag aarch64-jdk8u72-b16 for changeset f9b6277551dc
by gnu.andrew＠redhat.com 29 Feb '16

29 Feb '16

Changeset: 4c440540c962 Author: andrew Date: 2016-02-29 06:45 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/hotspot/rev/4c440540c962 Added tag aarch64-jdk8u72-b16 for changeset f9b6277551dc ! .hgtags

1 0

hg: aarch64-port/jdk8u/langtools: Added tag aarch64-jdk8u72-b16 for changeset b63515578554
by gnu.andrew＠redhat.com 29 Feb '16

29 Feb '16

Changeset: 109a626b4431 Author: andrew Date: 2016-02-29 06:45 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/langtools/rev/109a626b4431 Added tag aarch64-jdk8u72-b16 for changeset b63515578554 ! .hgtags

1 0