June 2015 - aarch64-port-dev

Support large codecache for JDK8
by Andrew Dinn 26 Nov '15

26 Nov '15

Attached for review is a patch which adds large codecache support to jdk8 (jdk7 version will be next). It passes basic smoke tests (java hello, javac Hello.java, netbeans build and run simple project). Ok to push? regards, Andrew Dinn -----------

3 7

barrier issue in cmpxchgptr implementation
by Tangwei (Euler) 30 Jun '15

30 Jun '15

Hi All, I checked the MacroAssembler::cmpxchgptr implementation in JVM, and found load-aquire/store-release followed by a full memory barrier used to simulate the behavior of X86 cmpxchg. Following is the code snapshot from the function for your reference. In my opinion, the cmpxchg must provide full bi-directional fence semantics. Is there anyone can help to explain why one membar in the end is enough for cmpxchg? Or one more memory barrier commented out is needed to add at the beginning? // membar(AnyAny) // is this needed? retry_load: ldaxr(tmp, addr); cmp(tmp, oldv); br(Assembler::NE, nope); stlxr(tmp, newv, addr); cbzw(tmp, succeed); b(retry_load); nope: membar(AnyAny); mov(oldv, tmp); I checked the source __cmpxchg_mb, it seems two memory barrier is added around cmpxchg. smp_mb(); ret = __cmpxchg(ptr, old, new, size); smp_mb(); But after checked intrinsic in GCC with following simple case, I found there is no barrier around load-acquire/store-release. I am a little confused now. Which instruction sequence should be chosen to simulate X86 cmpxchg? long foo (long *ptr, long old, long new) { return __sync_val_compare_and_swap (ptr, old, new); } Assembly: ldaxr x3, [x0] // 22 aarch64_load_exclusivedi [length = 4] cmp x3, x1 // 23 *cmpdi/1 [length = 4] bne .L3 // 24 *condjump [length = 4] stlxr w4, x2, [x0] // 25 aarch64_store_exclusivedi [length = 4] cbnz w4, .L2 // 26 *cbnesi1 [length = 4] Regards! wei

2 1

RFR: 8129426: aarch64: add support for PopCount in C2
by Edward Nevill 29 Jun '15

29 Jun '15

Hi, Aarch64 currently does not support the PopCountI and PopCountL nodes in aarch64.ad The following webrev adds support for these using the SIMD instructions 'cnt' and 'addv' http://cr.openjdk.java.net/~enevill/8129426/webrev.01/ This patch was contributed by alexander.alexeev(a)caviumnetworks.com The patch only modifies aarch64 specific files. I have merged the patch in and tested it with JTreg / hotspot with the following results. Original: Test results: passed: 847; failed: 13; error: 6 Revised: Test results: passed: 848; failed: 12; error: 6 The single additional failure in the original is the test FAILED: compiler/intrinsics/squaretolen/TestSquareToLen.java which is an intermittent failure in the original. I have benchmarked the patch on four different partner platforms. The average improvement was 2.6X for PopCountI and 2.5X for PopCountL. Please review and if OK I will push, Thanks, Ed.

4 17

RFR: 8129426: aarch64: add support for PopCount in C2
by Edward Nevill 29 Jun '15

29 Jun '15

Hi, Aarch64 currently does not support the PopCountI and PopCountL nodes in aarch64.ad The following webrev adds support for these using the SIMD instructions 'cnt' and 'addv' http://cr.openjdk.java.net/~enevill/8129426/webrev.04 This patch was contributed by alexander.alexeev(a)caviumnetworks.com The patch only modifies aarch64 specific files. I have merged the patch in and tested it with JTreg / hotspot with the following results for both original and revised Test results: passed: 858; failed: 4; error: 6 I have benchmarked the patch on four different partner platforms. The average improvement was 2.6X for PopCountI and 2.5X for PopCountL. Please review, Thanks, Ed.

3 2

RFR: 8086087: aarch64: add support for 64 bit vectors
by Edward Nevill 29 Jun '15

29 Jun '15

Hi, The following webrev adds support for 64 bit vectors (only) on aarch64 http://cr.openjdk.java.net/~enevill/8086087/webrev.02 Previously the vector code only supported 128 bit vectors. 32 bit vectors are not supported in this changeset but will be supported in a future changeset. I have tested this with JTreg hotspot with the following results Original: Test results: passed: 858; failed: 4; error: 6 Revised: Test results: passed: 857; failed: 5; error: 6 The additional test failure is compiler/intrinsics/muladd/TestMulAdd.java which fails intermittently with both original and revised versions (I'll take a look at that next:-). I have also benchmarked the Test*Vect tests from 6340864 in the hotspot test suite. The following are the average results I get on one of our partners HW (lower number is better). TestByteVect: 128-bit (11.77), 64-bit (4.36) TestShortVect: 128-bit (5.02), 64-bit (5.22) TestIntVect: 128-bit (7.81), 64-bit (7.70) TestLongVect: 128-bit (11.67), 64-bit (11.71) TestFloatVect: 128-bit (16.75), 64-bit (17.29) TestDoubleVect:128-bit (32.37), 64-bit (32.43) So the only test which shows an improvement is TestByteVect which shows a 2.7x speedup. The other tests are the same within the bounds of experimental error. The reason TestByteVect shows such an improvement is that with 128 bit vectors it is not being vectorized at all because the loop is not unrolled sufficiently to allow it to be vectorized, wheras with 64 bit vectors it is. Please review and let me know if this is OK to push? Ed. PS: For pushing an aarch64 specific change to hs-comp do I need 1 or 2 reviewers?

3 2

RFR: 8129426: aarch64: add support for PopCount in C2
by Edward Nevill 25 Jun '15

25 Jun '15

Hi, Aarch64 currently does not support the PopCountI and PopCountL nodes in aarch64.ad The following webrev adds support for these using the SIMD instructions 'cnt' and 'addv' http://cr.openjdk.java.net/~enevill/8129426/webrev.04 This patch was contributed by alexander.alexeev(a)caviumnetworks.com The patch only modifies aarch64 specific files. I have merged the patch in and tested it with JTreg / hotspot with the following results for both original and revised Test results: passed: 858; failed: 4; error: 6 I have benchmarked the patch on four different partner platforms. The average improvement was 2.6X for PopCountI and 2.5X for PopCountL. Please review, Thanks, Ed.

1 0

Scalar reduction
by Andrew Haley 25 Jun '15

25 Jun '15

Do you know if int scalar reduction supposed to work yet? This doesn't seem to be vectorized: int sum(int[] a) { int val = 0; for(int elem: a) val += elem; return val; } but this is: int[] sum(int[] a, int[] b, int[] result) { for(int i = 0; i < a.length; i++) result [i] = a[i] + b[i]; return result; } Hmmmm, doesn't seem to work on x86 either. Baffled. Andrew.

2 2

Re: [aarch64-port-dev ] RFR: 8129426: aarch64: add support for PopCount in C2
by Edward Nevill 24 Jun '15

24 Jun '15

On Tue, 2015-06-23 at 15:11 -0600, Alejandro E Murillo wrote: > On 6/23/2015 7:51 AM, Edward Nevill wrote: > > On Tue, 2015-06-23 at 11:32 +0100, Andrew Dinn wrote: > >> On 23/06/15 11:10, Andrew Haley wrote: > >>> On 22/06/15 17:14, Andrew Dinn wrote: > >>>> . . . > >>>> Well, you might not want to take this risk and instead add an explicit > >>>> zero of the upper half. But I think we need to be clear what risk we are > >>>> taking. > >>> It's this: if we don't explicitly zero the upper half we'll have to > >>> audit all the code which might present a sign-extended value (instead > >>> of a zero-extended one) in a register that's supposed to contain a > >>> jint. > >> Ok, let's play safe. If Ed tweaks the patch to zero the upper word we > >> can always revise that later if/when we decide we are feeling lucky. > >> > > OK. New webrev at > > > > http://cr.openjdk.java.net/~enevill/8129426/webrev.02/ > > > > All the best, > > Ed. > > > > > Hi, > to be consistent with similar integrations and to avoid potential > merging problems, > going forward please work with the hs-rt repo for this kind of changes, > as Volker has been doing. Hi Alejandro, I have rebased the patch on hs-rt. New webrev http://cr.openjdk.java.net/~enevill/8129426/webrev.03/ Does it look OK to push? Thanks, Ed.

2 3

RFR: 8086087: aarch64: add support for 64 bit vectors
by Edward Nevill 24 Jun '15

24 Jun '15

Hi, The following webrev based on the hs-rt repo http://cr.openjdk.java.net/~enevill/8086087/webrev.01 Adds support for 64 bit vectors on aarch64. Previously the vector code only supported 128 bit vectors. 32 bit vectors are not supported directly as aarch64 has no support for 32 bit vectors, however the above webrev will permit 32 bit vectors but just place them in a 64 bit vector. I have tested this with JTreg hotspot and get the same results before and after the change, viz, Test results: passed: 845; failed: 12; error: 6 I have also benchmarked the Test*Vect tests from 6340864 in the hotspot test suite. The following are the average results I get on one of our partners HW (lower number is better). TestByteVect: 128-bit (11.77), 64-bit (4.36) TestShortVect: 128-bit (5.02), 64-bit (5.22) TestIntVect: 128-bit (7.81), 64-bit (7.70) TestLongVect: 128-bit (11.67), 64-bit (11.71) TestFloatVect: 128-bit (16.75), 64-bit (17.29) TestDoubleVect:128-bit (32.37), 64-bit (32.43) So the only test which shows an improvement is TestByteVect which shows a 2.7x speedup. The other tests are the same within the bounds of experimental error. The reason TestByteVect shows such an improvement is that with 128 bit vectors it is not being vectorized at all because the loop is not unrolled sufficiently to allow it to be vectorized, wheras with 64 bit vectors it is. Please review and let me know if this is OK to push? Ed.

2 3

RFR: 8081294: aarch64: fails to build on ubuntu wily
by Edward Nevill 24 Jun '15

24 Jun '15

Hi, One of our partners has reported that jdk9 fails to build for aarch64 on ubuntu 'wily' The failing buildlog is here https://launchpad.net/ubuntu/+source/openjdk-9/9~b64-1ubuntu1/+build/7441971 The following webrev fixes this http://cr.openjdk.java.net/~enevill/8081294/webrev/ I have verified that this fixes the problem by cross compiling against a sysroot. Our partner has also verified that this patch fixes the build. As this is a change to shared code I will need someone to sponsor this and push it through JPRT. Thanks for your help, Ed

2 1