January 2016 - aarch64-port-dev

RFR(s): AARCH64: 8147805: C1 segmentation fault due to inline Unsafe::getAndSetObject
by Hui Shi 20 Jan '16

20 Jan '16

Hi All, Could some one help review this AArch64 C1 issue? Issue happens when inline unsafe.getAndSet(data) in C1 and UseCompressedOops flag is true, register is compressed for store, but it is not restored into decompressed form. Later compressed result is used as reference address and goes wrong. Bug: https://bugs.openjdk.java.net/browse/JDK-8147805 webrev: http://cr.openjdk.java.net/~hshi/8147805/webrev/ Small test case in http://cr.openjdk.java.net/~hshi/8147805/TestUnsafe.java Crash can be reproduced by java -XX:TieredStopAtLevel=3 -XX:+TieredCompilation -Xms4G -Xmx4G TestUnsafe In following method, n is stored two times, first in unsafe.getAndSet, second when store old.next. public Node foo(Node n) { Node old; old = this.getAndSet(n); // inline sun.misc.Unsafe::getAndSetObject here, shift first time for store old.next = n; // n is used again and store into old.next, shift again for store return old; } In generated assemlby, can see "x2" is shifted but not restored 0x0000007f943af3dc: lsr x2, x2, #3 // x2 is shifted but not restored 0x0000007f943af3e0: add x4, x1, #0xc 0x0000007f943af3e4: ldaxr w3, [x4] 0x0000007f943af3e8: stlxr w9, w2, [x4] 0x0000007f943af3ec: cbnz w9, 0x0000007f943af3e4 0x0000007f943af3f0: lsl x3, x3, #3 0x0000007f943af3f4: dmb ish 0x0000007f943af504: lsr x8, x2, #3 // x2 is shifted again and wrong 0x0000007f943af508: str w8, [x0,#16] 0x0000007f943af50c: lsr x2, x0, #9 0x0000007f943af510: strb wzr, [x2,x1,lsl #0] ;*putfield next ; - TestUnsafe::foo@11 (line 25) Patch is using rscratch1 to hold heap_oop address for store when UseCompressedOops is true. So later use still get correct object address. Regards Hui

3 3

RFR: 8146843: aarch64: add scheduling support for FP and vector instructions
by Edward Nevill 13 Jan '16

13 Jan '16

Hi, Please review the following webrev http://cr.openjdk.java.net/~enevill/8146843/webrev.1 This adds support for OptoScheduling of FP & Vector (Neon) instructions on aarch64 (aarch64 already has support for scheduling of scalar instructions). The following table shows the performance difference of this change. http://cr.openjdk.java.net/~enevill/8146843/vectest.html Note that the pipeline scheduling used in this change is based on partner C hardware because that is the only hardware I have the micro architecture details for. Unsurprisingly the performance difference is most noticeable for the in order cores (B & D). In a few cases the performance is worse. This seems to be due to it mis-scheduling data processing instructions at the cost of load store instructions on out of order cores. However I think that the overall performance improvement makes this change worthwhile. It may be possible in a future change to predicate individual pipeline classes on the core it is being run on, however this could rapidly lead to explosion in the size of aarch64.ad. Alternatively we could do some coarser predication on In Order vs Out of Order. I have tested the change with jtreg hotspot and langtools with the following results. Before: Hotspot: Test results: passed: 1,066; failed: 15; error: 18 Langtools: Test results: passed: 3,358; failed: 1; error: 4 After: Hotspot: Test results: passed: 1,073; failed: 11; error: 15 Langtools: Test results: passed: 3,358; failed: 1; error: 4 Thanks for the review, Ed.

2 1

RFR: 8146886: aarch64: fails to build following 8136525 and 8139864
by Edward Nevill 12 Jan '16

12 Jan '16

Hi, The following webrev fixed several build failures in aarch64 following recent merges. Webrev: http://cr.openjdk.java.net/~enevill/8146886/webrev/ Jira: https://bugs.openjdk.java.net/browse/JDK-8146886 Testing by building release and festdebug versions and by running jtreg hotspot and langtools. Jtreg hotspot: Test results: passed: 1,068; failed: 16; error: 15 JTreg langtools: Test results: passed: 3,358; failed: 1; error: 4 OK to push? Ed.

2 1

RFR: 8146678: aarch64: assertion failure: call instruction in an infinite loop
by Edward Nevill 08 Jan '16

08 Jan '16

Hi, Please review the following webrev http://cr.openjdk.java.net/~enevill/8146678/webrev/ JIRA Issue: https://bugs.openjdk.java.net/browse/JDK-8146678 This fixes an assertion in Relocation::pd_set_call_destination assert(addr() != x, "call instruction in an infinite loop"); which triggers following 8146286: aarch64: guarantee failures with large code cache sizes on jtreg test java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java The reason is that this change deliberately generates BL to self to avoid BL going out of range. The fix is to remove the assertion as it is no longer valid. Thanks, Ed.

2 1

RFR: 8146286: aarch64: guarantee failures with large code cache sizes on jtreg test java/lang/invoke/LFCaching10/LFMultiThreadCachingTest.java
by Edward Nevill 08 Jan '16

08 Jan '16

Hi, The following webrev http://cr.openjdk.java.net/~enevill/8146286/webrev.0/ JIRA Issue: https://bugs.openjdk.java.net/browse/JDK-8146286 The problem is that during code buffer expansion the code buffer can be moved so that a BL is no longer in range. Normally this would resolve to the targets trampoline. However this is inhibited during code buffer expansion because of the following in get_trampoline_for() address trampoline_stub_Relocation::get_trampoline_for(address call, nmethod* code) { // There are no relocations available when the code gets relocated // because of CodeBuffer expansion. if (code->relocation_size() == 0) return NULL; The problem is that the relocs have not been created yet, so get_trampoline_for cannot resolve to the trampoline. The solution I have adopted is to always generate a BL to self in MacroAssembler::trampoline_call. In Relocation::pd_call_destination when it detects a call to self it does not attempt to do the relocation but just leaves it as a call to self (there is no point in trying to relocate the call to self to point to the original destination since that is in the old copy of the code buffer and could be out of range). During final relocation the call to self is then relocated to the correct value. Repeated testing with the above test shows that the problem has been resolved. I have also tested with jtreg hotspot/langtools and jdk, before and after patching and with and without -XX:+ReservedCodeCacheSize=256m with no additional failures. OK to push? Ed.

2 4

JTREG, SPECjbb2013 and Hadoop/Terasort results for OpenJDK 8 on AArch64
by Edward Nevill 08 Jan '16

08 Jan '16

This is a summary of the JTREG test results =========================================== The build and test results are cycled every 10 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/openjdk8-jtreg-nightly-tests/summary/2016/007/sum… ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2015/jul/08 pass: 636; fail: 45; error: 5 Build 1: aarch64/2015/jul/21 pass: 637; fail: 45; error: 5 Build 2: aarch64/2015/sep/04 pass: 636; fail: 46; error: 5 Build 3: aarch64/2015/sep/08 pass: 636; fail: 46; error: 5 Build 4: aarch64/2015/oct/22 pass: 637; fail: 45; error: 5 Build 5: aarch64/2015/oct/27 pass: 637; fail: 45; error: 5 Build 6: aarch64/2015/oct/29 pass: 637; fail: 45; error: 5 Build 7: aarch64/2015/nov/04 pass: 637; fail: 45; error: 5 Build 8: aarch64/2015/nov/27 pass: 637; fail: 45; error: 5 Build 9: aarch64/2016/jan/07 pass: 637; fail: 45; error: 5 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2015/jul/08 pass: 5,485; fail: 242; error: 22 Build 1: aarch64/2015/jul/21 pass: 5,502; fail: 233; error: 18 Build 2: aarch64/2015/sep/04 pass: 5,477; fail: 254; error: 22 Build 3: aarch64/2015/sep/08 pass: 5,477; fail: 254; error: 22 Build 4: aarch64/2015/oct/22 pass: 5,482; fail: 254; error: 17 Build 5: aarch64/2015/oct/27 pass: 5,472; fail: 259; error: 22 Build 6: aarch64/2015/oct/29 pass: 5,503; fail: 229; error: 21 Build 7: aarch64/2015/nov/04 pass: 5,503; fail: 228; error: 22 Build 8: aarch64/2015/nov/27 pass: 5,506; fail: 227; error: 20 Build 9: aarch64/2016/jan/07 pass: 5,504; fail: 229; error: 20 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2015/jul/08 pass: 3,080; error: 11 Build 1: aarch64/2015/jul/21 pass: 3,081; error: 10 Build 2: aarch64/2015/sep/04 pass: 3,078; error: 13 Build 3: aarch64/2015/sep/08 pass: 3,078; error: 13 Build 4: aarch64/2015/oct/22 pass: 3,077; error: 14 Build 5: aarch64/2015/oct/27 pass: 3,081; error: 10 Build 6: aarch64/2015/oct/29 pass: 3,079; error: 12 Build 7: aarch64/2015/nov/04 pass: 3,080; error: 11 Build 8: aarch64/2015/nov/27 pass: 3,078; error: 13 Build 9: aarch64/2016/jan/07 pass: 3,076; error: 15 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2015/jul/08 pass: 644; fail: 37; error: 5 Build 1: aarch64/2015/jul/21 pass: 645; fail: 37; error: 5 Build 2: aarch64/2015/sep/04 pass: 645; fail: 37; error: 5 Build 3: aarch64/2015/sep/08 pass: 645; fail: 37; error: 5 Build 4: aarch64/2015/oct/22 pass: 644; fail: 38; error: 5 Build 5: aarch64/2015/oct/27 pass: 644; fail: 38; error: 5 Build 6: aarch64/2015/oct/29 pass: 645; fail: 37; error: 5 Build 7: aarch64/2015/nov/04 pass: 643; fail: 39; error: 5 Build 8: aarch64/2015/nov/27 pass: 643; fail: 38; error: 6 Build 9: aarch64/2016/jan/07 pass: 644; fail: 38; error: 5 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2015/jul/08 pass: 5,506; fail: 221; error: 22 Build 1: aarch64/2015/jul/21 pass: 5,512; fail: 217; error: 24 Build 2: aarch64/2015/sep/04 pass: 5,471; fail: 257; error: 25 Build 3: aarch64/2015/sep/08 pass: 5,471; fail: 257; error: 25 Build 4: aarch64/2015/oct/22 pass: 5,489; fail: 241; error: 23 Build 5: aarch64/2015/oct/27 pass: 5,495; fail: 234; error: 24 Build 6: aarch64/2015/oct/29 pass: 5,521; fail: 209; error: 23 Build 7: aarch64/2015/nov/04 pass: 5,509; fail: 222; error: 22 Build 8: aarch64/2015/nov/27 pass: 5,517; fail: 214; error: 22 Build 9: aarch64/2016/jan/07 pass: 5,521; fail: 208; error: 24 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2015/jul/08 pass: 3,083; error: 8 Build 1: aarch64/2015/jul/21 pass: 3,081; error: 10 Build 2: aarch64/2015/sep/04 pass: 3,078; error: 13 Build 3: aarch64/2015/sep/08 pass: 3,078; error: 13 Build 4: aarch64/2015/oct/22 pass: 3,082; fail: 2; error: 7 Build 5: aarch64/2015/oct/27 pass: 3,083; error: 8 Build 6: aarch64/2015/oct/29 pass: 3,081; error: 10 Build 7: aarch64/2015/nov/04 pass: 3,080; fail: 1; error: 10 Build 8: aarch64/2015/nov/27 pass: 3,079; error: 12 Build 9: aarch64/2016/jan/07 pass: 3,079; error: 12 Previous results can be found here: http://openjdk.linaro.org/openjdk8-jtreg-nightly-tests/index.html SPECjbb2013 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2013 composite tests and compares the performance against the baseline performance of the server compiler taken on 2014-04-01. In accordance with [1], the SPECjbb2013 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 1.16x Relative performance: Server critical-jOPS (nc): 1.46x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/SPECjbb2013-1.00-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 49.18, Server: 91.06 Client 49.18 / Client 2014-04-01 (43.00): 1.14x Server 91.06 / Server 2014-04-01 (71.00): 1.28x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 10 days. 2015-07-08 pass rate: 11556/11556, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/189/results/ 2015-07-21 pass rate: 11556/11556, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/202/results/ 2015-09-04 pass rate: 11555/11556, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/247/results/ 2015-09-08 pass rate: 11555/11556, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/251/results/ 2015-10-22 pass rate: 11558/11558, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/295/results/ 2015-10-27 pass rate: 11558/11558, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/300/results/ 2015-10-29 pass rate: 11558/11558, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/302/results/ 2015-11-04 pass rate: 11558/11558, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/308/results/ 2015-11-27 pass rate: 11558/11558, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/331/results/ 2016-01-07 pass rate: 11558/11558, results: http://openjdk.linaro.org/jcstress-nightly-runs/2016/007/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jcstress-nightly-runs/

1 0

RFR: JDK 7: Add support for large code cache
by Edward Nevill 07 Jan '16

07 Jan '16

Hi, The following webrev adds support for large code caches (>128M) to JDK 7 for aarch64. http://cr.openjdk.java.net/~enevill/jdk7_largecode/webrev.01/ Tested with jtreg hotspot & langtools hotspot(original): Test results: passed: 297; failed: 12; error: 2 hotspot(256m cache): Test results: passed: 298; failed: 11; error: 2 langtools(original): Test results: passed: 1,973; failed: 1 langtools(256m cache): Test results: passed: 1,973; failed: 1 OK to push? Ed.

2 1

hg: aarch64-port/jdk8/hotspot: 2 new changesets
by edward.nevill＠gmail.com 06 Jan '16

06 Jan '16

Changeset: 86ebc388af0b Author: enevill Date: 2016-01-05 17:40 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/86ebc388af0b Fix client build after addition of large code cache support ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/vm_version_aarch64.cpp Changeset: 0e3fa1efe9b1 Author: enevill Date: 2015-12-29 16:47 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/0e3fa1efe9b1 8146286: aarch64: guarantee failures with large code cache sizes on jtreg test java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java Summary: patch trampoline calls with special case bl to itself which does not cause guarantee failure Reviewed-by: aph ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/relocInfo_aarch64.cpp

1 0

RFR: aarch64: JDK 8: Get client build going again
by Edward Nevill 06 Jan '16

06 Jan '16

Hi, The following webrev fixes the JDK 8 client build which was broken by the addition of large code cache support. http://cr.openjdk.java.net/~enevill/jdk8_client_build/webrev.0 The problem is that the trampoline code in macroAssembler_aarch64 references class Compile which is only declared in C2. The fix I have adopted is to conditionalise this code on COMPILER2. This means that the client compiler will not support code cache size > 128M which is the same behaviour as before the addition of large code cache support. The main motivation for this is to get the overnight testing going again as currently it has stopped because it cannot do a client build. OK? Ed.

2 3