March 2016 - aarch64-port-dev

hg: aarch64-port/jdk8u/jaxp: Added tag aarch64-jdk8u77-b03 for changeset 99056017b4e3
by gnu.andrew＠redhat.com 29 Mar '16

29 Mar '16

Changeset: 09288fbc8835 Author: andrew Date: 2016-03-23 17:20 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jaxp/rev/09288fbc8835 Added tag aarch64-jdk8u77-b03 for changeset 99056017b4e3 ! .hgtags

1 0

hg: aarch64-port/jdk8u/corba: Added tag aarch64-jdk8u77-b03 for changeset c44425453bfa
by gnu.andrew＠redhat.com 29 Mar '16

29 Mar '16

Changeset: 1f88c12e40b2 Author: andrew Date: 2016-03-23 17:20 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/corba/rev/1f88c12e40b2 Added tag aarch64-jdk8u77-b03 for changeset c44425453bfa ! .hgtags

1 0

hg: aarch64-port/jdk8u: Added tag aarch64-jdk8u77-b03 for changeset 86030362b0c5
by gnu.andrew＠redhat.com 29 Mar '16

29 Mar '16

Changeset: ed73b014b78b Author: andrew Date: 2016-03-23 17:20 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/rev/ed73b014b78b Added tag aarch64-jdk8u77-b03 for changeset 86030362b0c5 ! .hgtags

1 0

RFR: 8151775: aarch64: add support for 8.1 LSE atomic operations
by Edward Nevill 29 Mar '16

29 Mar '16

Hi, The following webrev adds support for 8.1 LSE atomic operations http://cr.openjdk.java.net/~enevill/8151775/webrev It also adds to CAS cases which I missed in the previous patch for 8.1 CAS instructions. Tested with a clean run through jcstress. Thanks, Ed

2 3

RFR: aarch64: improve _unsafe_arraycopy stub routine
by Felix Yang 29 Mar '16

29 Mar '16

Hi, Please review webrev: http://cr.openjdk.java.net/~fyang/8152840/webrev.00/ JIRA issue: https://bugs.openjdk.java.net/browse/JDK-8152840 Patch improves _unsafe_arraycopy stub by checking the alignment of the src, dest, and count, and call some faster arraycopy stubs (say StubRoutines::_jshort_arraycopy). About 1%+ performance gain on Spark Terasort benchmark by this improvement. Here is the disassembly of the new stub routine code: StubRoutines::unsafe_arraycopy [0x0000007f8c93a000, 0x0000007f8c93a040[ (64 bytes) 0x0000007f8c93a000: stp x29, x30, [sp,#-16]! 0x0000007f8c93a004: mov x29, sp 0x0000007f8c93a008: orr x8, x0, x1 0x0000007f8c93a00c: orr x8, x8, x2 0x0000007f8c93a010: and x8, x8, #0x7 0x0000007f8c93a014: cbz x8, Stub::unsafe_arraycopy+56 0x0000007f8c93a038 0x0000007f8c93a018: and x8, x8, #0x3 0x0000007f8c93a01c: cbz x8, Stub::unsafe_arraycopy+48 0x0000007f8c93a030 0x0000007f8c93a020: tbz w8, #0, Stub::unsafe_arraycopy+40 0x0000007f8c93a028 0x0000007f8c93a024: b Stub::jbyte_arraycopy+8 0x0000007f8c938d68 0x0000007f8c93a028: lsr x2, x2, #1 0x0000007f8c93a02c: b Stub::jshort_arraycopy+8 0x0000007f8c938fd4 0x0000007f8c93a030: lsr x2, x2, #2 0x0000007f8c93a034: b Stub::jint_arraycopy+8 0x0000007f8c9392fc 0x0000007f8c93a038: lsr x2, x2, #3 0x0000007f8c93a03c: b Stub::arrayof_jlong_arraycopy+8 0x0000007f8c9393d4 Tested with JTreg hotspot & langtools, is it OK? BTW: The _unsafe_arraycopy and _generic_arraycopy stubs are missing for jdk8u, I would like to backport them from jdk9 later. Thanks, Felix

2 1

RFR: 8152537 : aarch64: Make use of CBZ and CBNZ when comparing unsigned values with zero
by Felix Yang 24 Mar '16

24 Mar '16

Hi, Please review webrev: http://cr.openjdk.java.net/~fyang/8152537/webrev.00 JIRA issue: https://bugs.openjdk.java.net/browse/JDK-8152537 For many times I noticed the following C2 JIT code in specJBB2005 and other benchmarks: 0x0000007f7cd8b4f8: ldr w11, [x17,#12] ;*arraylength ; - java.lang.String::hashCode@13 (line 1467) ; implicit exception: dispatches to 0x0000007f7cd8b604 0x0000007f7cd8b4fc: cmp w11, #0x0 0x0000007f7cd8b500: b.le 0x0000007f7cd8b5e8 ;*ifle ; - java.lang.String::hashCode@14 (line 1467) 0x0000007f7cd8b504: cmp w11, #0x0 0x0000007f7cd8b508: b.ls 0x0000007f7cd8b5f0 0x0000007f7cd8b50c: sub w12, w11, #0x1 0x0000007f7cd8b510: cmp w12, w11 0x0000007f7cd8b514: b.cs 0x0000007f7cd8b5f0 ;*bipush ; - java.lang.String::hashCode@33 (line 1471) 0x0000007f7cd8b518: ldrh w0, [x17,#16] ;*caload ; - java.lang.String::hashCode@39 (line 1471) 0x0000007f7cd8b51c: sub w13, w11, #0x3 0x0000007f7cd8b520: cmp w12, w13 0x0000007f7cd8b524: orr w16, wzr, #0x80000000 0x0000007f7cd8b528: lsl w10, w0, #5 0x0000007f7cd8b52c: csel w16, w16, w13, lt 0x0000007f7cd8b530: orr w1, wzr, #0x1 0x0000007f7cd8b534: sub w14, w10, w0 0x0000007f7cd8b538: cmp w16, #0x1 0x0000007f7cd8b53c: b.le 0x0000007f7cd8b5a4 0x0000007f7cd8b540: b 0x0000007f7cd8b554 Patch combines the following two instructions into one cbzw instruction: 0x0000007f7cd8b504: cmp w11, #0x0 0x0000007f7cd8b508: b.ls 0x0000007f7cd8b5f0 Tested with JTreg hotspot, langtools and jdk. Is it OK? Thanks, Felix

2 1

JEP 254: Compact Strings
by Andrew Haley 21 Mar '16

21 Mar '16

https://bugs.openjdk.java.net/browse/JDK-8054307 I'd like to get Compact Strings working properly on AArch64. Some of what we'll need is already there, but much of it is not. We need: - String.equals - String.compareTo - String.indexOf - String.compress - String.inflate - StringCoding.hasNegatives We already have UTF-16 (UU) variants of these, and Latin1 (LL) variants of some. But we need UL and LU variants of all of them. I don't know how much of these should use the SIMD instruction set. I would guess quite a lot, but not every AArch64 has a very fast SIMD unit, and there are penalties for misaligned loads and stores. Goal: Improved SPECjbb 2005 performance. (I'm aware that this benchmark is retired, but it's still a useful model or a representative server load.) I'm working on String.equals. I'd appreciate help with some of the others. I intend to create JBS entries for the tasks as we go along. Thanks, Andrew.

1 0

RFR: 8151502: aarch64: optimize pd_disjoint_words and pd_conjoint_words
by Edward Nevill 09 Mar '16

09 Mar '16

Hi, Please review the following webrev http://cr.openjdk.java.net/~enevill/8151502/webrev/ This optimizes Copy::pd_disjoint_words and Copy::pd_conjoint_words using inline assembler. These routines are heavily used in GC and the aim is to improve the overall performance of GC. Tested in JMH using the following GCStress program. http://cr.openjdk.java.net/~enevill/8151502/JMHSample_97_GCStress.java JMH jar file: http://cr.openjdk.java.net/~enevill/8151502/benchmarks.jar The following are the results I get Original: /home/ed/images/jdk9-orig/bin/java -jar target/benchmarks.jar -i 5 -wi 5 -f 5 Result "gcstress": 24636979.087 ?(99.9%) 267838.773 us/op [Average] (min, avg, max) = (24102797.710, 24636979.087, 25372022.370), stdev = 357557.099 CI (99.9%): [24369140.314, 24904817.860] (assumes normal distribution) # Run complete. Total time: 00:20:55 Benchmark Mode Cnt Score Error Units JMHSample_97_GCStress.gcstress avgt 25 24636979.087 ? 267838.773 us/op --------------------------------------------------------------------------- Optimized: /home/ed/images/jdk9-test/bin/java -jar target/benchmarks.jar -i 5 -wi 5 -f 5 Result "gcstress": 20164420.762 ?(99.9%) 280305.425 us/op [Average] (min, avg, max) = (19738992.960, 20164420.762, 21137460.090), stdev = 374199.723 CI (99.9%): [19884115.337, 20444726.188] (assumes normal distribution) # Run complete. Total time: 00:17:06 Benchmark Mode Cnt Score Error Units JMHSample_97_GCStress.gcstress avgt 25 20164420.762 ? 280305.425 us/op This shows approx 22% performance improvement on this benchmark. I have also included a small bug fix to Array copy when using -XX:+UseSIMDForMemoryOps. I had fixed this previously, but somehow it fell out. All the best, Ed

2 4

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