November 2017 - aarch64-port-dev

RFR: 8191954: AArch64: disable UseCISCSpill in C2
by Ningsheng Jian 20 Mar '18

20 Mar '18

Hi, Please help to review. JBS: https://bugs.openjdk.java.net/browse/JDK-8191954 Webrev: http://cr.openjdk.java.net/~njian/8191954/webrev.00/ This sets UseCISCSpill to false on AArch64, as we actually don't use that. jtreg tests passed with fastdebug build. Thanks, Ningsheng

4 7

RFR: 8191955: AArch64: incorrect prefetch distance causes an internal error
by Ningsheng Jian 04 Dec '17

04 Dec '17

Hi, Please help to review this small fix for AArch64. JBS: https://bugs.openjdk.java.net/browse/JDK-8191955 (with some descriptions) Webrev: http://cr.openjdk.java.net/~njian/8191955/webrev.00/ An unexpected distance triggers the error for PRFM instruction generation. This patch will warn and fix the unexpected input value. jtreg passed with fastdebug build. OK for 10? Thanks, Ningsheng

4 11

Re: [aarch64-port-dev ] RFR(S) 8189439: Parameters type profiling is not performed from aarch64 interpreter
by Boris 01 Dec '17

01 Dec '17

[this time in plain text] Please review bugfix to enable parameters type profiling missing in aarch64 interpreter to make it consistent with other ports. Additionally to aarch64 specific change I am going to add shared jtreg test to discover the case I have fixed. The test is very similar to TestArrayCopyNoInitDeopt.java (see JDK-8188221, Return type profiling is not performed from aarch64 interpreter). The test expects to see additional C2 deoptimization caused by speculative type check when profiling data became outdated. Existing profile_parameters_type() got minor fix and it is now used in interpreted method entries. CR: https://bugs.openjdk.java.net/browse/JDK-8189439 Webrew: http://cr.openjdk.java.net/~dchuyko/8189439/webrev.00/ Tested with jtreg on ARM64, X86. New test works Ok on X86, and the given change fixes test fail on ARM64. Thanks, Boris Ulasevich

7 14

JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64
by ci_notify＠linaro.org 30 Nov '17

30 Nov '17

This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2017/333… ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 1,445; fail: 15 Build 1: aarch64/2017/nov/23 pass: 1,448; fail: 12 Build 2: aarch64/2017/nov/25 pass: 1,456; fail: 12; error: 1 Build 3: aarch64/2017/nov/27 pass: 1,457; fail: 11; error: 1 Build 4: aarch64/2017/nov/29 pass: 1,546; fail: 14 3 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 7,490; fail: 739; error: 22 Build 1: aarch64/2017/nov/23 pass: 7,505; fail: 728; error: 22 Build 2: aarch64/2017/nov/25 pass: 7,531; fail: 697; error: 27 Build 3: aarch64/2017/nov/27 pass: 7,507; fail: 730; error: 18 Build 4: aarch64/2017/nov/29 pass: 7,501; fail: 737; error: 18 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 3,812; fail: 4; error: 1 Build 1: aarch64/2017/nov/23 pass: 3,817; fail: 5; error: 1 Build 2: aarch64/2017/nov/25 pass: 3,818; fail: 4; error: 1 Build 3: aarch64/2017/nov/27 pass: 3,814; fail: 5; error: 4 Build 4: aarch64/2017/nov/29 pass: 3,820; fail: 3 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 1,449; fail: 16 Build 1: aarch64/2017/nov/23 pass: 1,452; fail: 13 Build 2: aarch64/2017/nov/25 pass: 1,460; fail: 13; error: 1 Build 3: aarch64/2017/nov/27 pass: 1,460; fail: 13; error: 1 Build 4: aarch64/2017/nov/29 pass: 1,550; fail: 15 3 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 7,508; fail: 721; error: 22 Build 1: aarch64/2017/nov/23 pass: 7,502; fail: 728; error: 25 Build 2: aarch64/2017/nov/25 pass: 7,511; fail: 715; error: 29 Build 3: aarch64/2017/nov/27 pass: 7,528; fail: 705; error: 22 Build 4: aarch64/2017/nov/29 pass: 7,512; fail: 719; error: 25 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 3,812; fail: 4; error: 1 Build 1: aarch64/2017/nov/23 pass: 3,816; fail: 4; error: 3 Build 2: aarch64/2017/nov/25 pass: 3,819; fail: 4 Build 3: aarch64/2017/nov/27 pass: 3,819; fail: 3; error: 1 Build 4: aarch64/2017/nov/29 pass: 3,819; fail: 3; error: 1 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 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.01x Relative performance: Server critical-jOPS (nc): 0.89x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-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: 68.85, Server: 114.76 Client 68.85 / Client 2014-04-01 (43.00): 1.60x Server 114.76 / Server 2014-04-01 (71.00): 1.62x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2017-11-22 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/325/results/ 2017-11-24 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/327/results/ 2017-11-26 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/329/results/ 2017-11-28 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/331/results/ 2017-11-30 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/333/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/

1 0

Re: [aarch64-port-dev ] RFR: 8189596: AArch64: implementation for Thread-local handshakes
by Andrew Haley 29 Nov '17

29 Nov '17

On 24/11/17 10:36, Erik Österlund wrote: > By placing loading the local poll value with ldar *only* in the native > wrapper wakeup function, you avoid these issues. OK, thanks. http://cr.openjdk.java.net/~aph/8189596-2 -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

3 4

JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64
by ci_notify＠linaro.org 28 Nov '17

28 Nov '17

This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2017/331… ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 1,445; fail: 15 Build 1: aarch64/2017/nov/23 pass: 1,448; fail: 12 Build 2: aarch64/2017/nov/25 pass: 1,456; fail: 12; error: 1 Build 3: aarch64/2017/nov/27 pass: 1,457; fail: 11; error: 1 3 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 7,490; fail: 739; error: 22 Build 1: aarch64/2017/nov/23 pass: 7,505; fail: 728; error: 22 Build 2: aarch64/2017/nov/25 pass: 7,531; fail: 697; error: 27 Build 3: aarch64/2017/nov/27 pass: 7,507; fail: 730; error: 18 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 3,812; fail: 4; error: 1 Build 1: aarch64/2017/nov/23 pass: 3,817; fail: 5; error: 1 Build 2: aarch64/2017/nov/25 pass: 3,818; fail: 4; error: 1 Build 3: aarch64/2017/nov/27 pass: 3,814; fail: 5; error: 4 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 1,449; fail: 16 Build 1: aarch64/2017/nov/23 pass: 1,452; fail: 13 Build 2: aarch64/2017/nov/25 pass: 1,460; fail: 13; error: 1 Build 3: aarch64/2017/nov/27 pass: 1,460; fail: 13; error: 1 3 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 7,508; fail: 721; error: 22 Build 1: aarch64/2017/nov/23 pass: 7,502; fail: 728; error: 25 Build 2: aarch64/2017/nov/25 pass: 7,511; fail: 715; error: 29 Build 3: aarch64/2017/nov/27 pass: 7,528; fail: 705; error: 22 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 3,812; fail: 4; error: 1 Build 1: aarch64/2017/nov/23 pass: 3,816; fail: 4; error: 3 Build 2: aarch64/2017/nov/25 pass: 3,819; fail: 4 Build 3: aarch64/2017/nov/27 pass: 3,819; fail: 3; error: 1 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 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.01x Relative performance: Server critical-jOPS (nc): 0.71x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-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: 69.88, Server: 115.7 Client 69.88 / Client 2014-04-01 (43.00): 1.63x Server 115.7 / Server 2014-04-01 (71.00): 1.63x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2017-11-22 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/325/results/ 2017-11-24 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/327/results/ 2017-11-26 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/329/results/ 2017-11-28 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/331/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/

1 0

JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64
by ci_notify＠linaro.org 26 Nov '17

26 Nov '17

This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2017/329… ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 1,445; fail: 15 Build 1: aarch64/2017/nov/23 pass: 1,448; fail: 12 Build 2: aarch64/2017/nov/25 pass: 1,456; fail: 12; error: 1 3 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 7,490; fail: 739; error: 22 Build 1: aarch64/2017/nov/23 pass: 7,505; fail: 728; error: 22 Build 2: aarch64/2017/nov/25 pass: 7,531; fail: 697; error: 27 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 3,812; fail: 4; error: 1 Build 1: aarch64/2017/nov/23 pass: 3,817; fail: 5; error: 1 Build 2: aarch64/2017/nov/25 pass: 3,818; fail: 4; error: 1 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 1,449; fail: 16 Build 1: aarch64/2017/nov/23 pass: 1,452; fail: 13 Build 2: aarch64/2017/nov/25 pass: 1,460; fail: 13; error: 1 3 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 7,508; fail: 721; error: 22 Build 1: aarch64/2017/nov/23 pass: 7,502; fail: 728; error: 25 Build 2: aarch64/2017/nov/25 pass: 7,511; fail: 715; error: 29 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 3,812; fail: 4; error: 1 Build 1: aarch64/2017/nov/23 pass: 3,816; fail: 4; error: 3 Build 2: aarch64/2017/nov/25 pass: 3,819; fail: 4 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 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.03x Relative performance: Server critical-jOPS (nc): 0.88x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-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: 70.22, Server: 115.7 Client 70.22 / Client 2014-04-01 (43.00): 1.63x Server 115.7 / Server 2014-04-01 (71.00): 1.63x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2017-11-22 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/325/results/ 2017-11-24 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/327/results/ 2017-11-26 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/329/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/

1 0

Re: [aarch64-port-dev ] RFR: 8189596: AArch64: implementation for Thread-local handshakes
by Andrew Dinn 24 Nov '17

24 Nov '17

On 24/11/17 15:10, Erik Österlund wrote: > On 2017-11-24 15:39, Andrew Dinn wrote: >> The one detail I am still not sure of is how this design ensures that >> the benign races in JIT/interpreter ever come to an end. What guarantees >> that JITted code or the interpreter actually performs an acquiring load >> and thereby notices a change to the armed poll value? That might take a >> very long time (if it happens at all?). > > The JMM defines opaque stores as stores that among other properties > guarantee progress: the store will eventually become observable to other > threads. The stores that arm the thread-local polls use a > release_store(), which is strictly stronger than opaque on each platform > (and hence have the guarantee that they will "eventually" become > observable to opaque loads). Therefore, the fast-path in JIT-compiled > code and interpreter code are guaranteed to "eventually" observe those > stores with opaque loads (and ldr is an opaque load). When they do, they > will jump into the VM (directly or through a trampoline), and perform > the acquiring load on the thread-local poll, used before loading the > global state. > > As for how long time it takes for the stores to become eventually > observable by remote loads, I imagine it should be no worse than the > delay of the TLB shootdown event. And just for completeness for this > discussion: the arming of the local polls is followed by a fence() which > performs a dmb ish in your GCC intrinsics. Well, that's really what I was thinking about with the original question. I understand that writes will become visible "eventually". I'm just concerned to know what sort of upper bound is implied by that word (theoretical might be interesting but I'm more interested in practical). This is the mechanism intended to halt individual threads or all threads. If there is any possibility of some extended delay -- especially in the latter case -- then that would merit quantifying. I assume "no worse than the delay of the TLB shootdown event" means "TLB shootdown relies on the same sort of benign race"? If so that doesn't help quantify anything except to say that prior experience has not shown any significant delay (so far as we know). regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

1 0

RFR: 8189596: AArch64: implementation for Thread-local handshakes
by Andrew Haley 24 Nov '17

24 Nov '17

It was quite tricky to get this one right. Sime notes: I deleted LIR_Assembler::poll_for_safepoint because it's dead code. I set ThreadLocalHandshakes to true. This follows x86-64 and is probably the right thing to do, but it does have the disadvantage that it considerably extends the time to safepoint for interpreted code because we only poll at branches. I think this is probably a bad idea, but again it's the same as x86-64. OTOH, checking the safepoint bit at every bytecode would seriously bloat the interpreter. Oh dear. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

2 4

Re: [aarch64-port-dev ] RFR: 8189596: AArch64: implementation for Thread-local handshakes
by Andrew Dinn 24 Nov '17

24 Nov '17

On 24/11/17 10:36, Erik Österlund wrote: > By placing loading the local poll value with ldar *only* in the native > wrapper wakeup function, you avoid these issues. > Another approach you may elect to use is to only in the native wrapper > load both the thread-local poll value and the > SafepointSynchronize::_state, when filtering slow paths to avoid this > unfortunate race. I can see why an ldar (actually ldarw) is needed when safepoint_poll is called from the nativewrapper. Can you explain why ldar is not needed for *all* calls to safepoint_poll? > I have a bunch of other ideas as well exploiting dependent loads, but > thought maybe I should start the conversation and see what you think > before running off too much regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

2 1