October 2018 - aarch64-port-dev

AARCH64 support for lworld
by Dmitry Samersoff 08 Sep '19

08 Sep '19

Hello Everybody, I started implementation of AARCH64 support for lworld. I'm on very early stage so any advices are highly appreciated. Should I file a CR for this task somewhere? What is correct way to do it? -Dmitry -- Dmitry Samersoff http://devnull.samersoff.net * There will come soft rains ...

6 28

RFC: 64 bit literal oops
by Stuart Monteith 14 Feb '19

14 Feb '19

Hello, I've been testing my patch to make literal oops 64-bit rather than 48-bit. This is a necessary prerequisite for ZGC to operate on aarch64 using tagged pointers. I'm not submitting this in it's final form, but just for a view on whether this is the proper way to do this. The patch is here: http://cr.openjdk.java.net/~smonteith/oop64/webrev-20181002/ I've tested it against jtreg and G1GC, and get clean results as compared to without the patch. No issues are apparent running SPECjbb-2015. There are essentially 7 changes: 1. There is a new options: -XX:+Use64BitLiteralOops 2. MacroAssembler::patch_oop(address,address) patches 64-bit addresses if the flag is enabled. 3. MacroAssembler::target_addr_for_insn(address, unsigned) is modified to pull out a 64-bit target address, if there is an extra movk, and then calls ShouldNotReachHere(). 4. MacroAssembler::mov(Register, Address) has been changed to call movptr with a flag set if the address is an Oop. 5. MacroAssembler::movptr(Register, uintptr_t) has been modified to take a flag indicating if it is an oop that is being emitted. If Use64BitLiteralOops has been set, then an additional movk is emitted to make up the 64 bit literal. 6. NativeInstruction::is_oop_at(int) was added, to detect if an oop exists at the address. 7. NativeMovConstReg::next_instruction_address() has been changed to handle get the address after "movz, movk, movk" and with 64 bit oops "movz, movk, movk, movk." (6) has never been observed,, so I don't consider it tested - there aren't circumstances where it returns true, so arguably it it should be replaced by an appropriate assert. Likewise, (3) is also an unnecessary change - the ShouldNotReachHere() never traps during testing - it was left in for review purposes. It has been mentioned to me that we could just use 64-bit literals, as that would make things simpler - I look forward to people's opinions. It was also mentioned ages ago that in future the coloured bits could be made irrelevant for ZGC. There is the up and coming 52-bit VA scheme for Arm v8. If we are to use >48 bits of address space we will have to ask for it explicitly, in which case we'd need to use 64 bit oops. The class metadata could remain 48-bit in that case. There is an interesting presentation on 52-bit VA here: https://connect.linaro.org/resources/yvr18/yvr18-119/ BR, Stuart

4 8

RFR(M): 8212043: Add floating-point Math.min/max intrinsics
by Pengfei Li (Arm Technology China) 13 Dec '18

13 Dec '18

Hi, I would like to enable intrinsics of floating-point Math.min/max methods on AArch64. Could anyone help review this change? Webrev: http://cr.openjdk.java.net/~pli/rfr/8212043/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8212043 Below is the description of Math.max(double,double) in Java API doc. Behaviors of the other 3 methods are similar. "Returns the greater of two double values. That is, the result is the argument closer to positive infinity. If the arguments have the same value, the result is that same value. If either value is NaN, then the result is NaN. Unlike the numerical comparison operators, this method considers negative zero to be strictly smaller than positive zero. If one argument is positive zero and the other negative zero, the result is positive zero." [1] In AArch64 floating-point instruction set, the fmax instruction[2] has exactly the same behavior to the API description above. So these min/max calculations can be done in one single instruction. I also added a jtreg case[3] in this change to test these special arguments, including +0.0, -0.0, +inf, -inf and NaN. I ran the full jtreg test and no new issues were found. As I'm not familiar with other ISAs, intrinsics are enabled only on AArch64 in this change. I hope someone else can enable them on other platforms, if possible. [1] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/Math… [2] https://developer.arm.com/docs/dui0801/latest/a64-floating-point-instructio… [3] http://cr.openjdk.java.net/~pli/rfr/8212043/webrev.00/test/hotspot/jtreg/co… -- Thanks, Pengfei

3 27

RFR(S): 8205421 - AARCH64: StubCodeMark should be placed after alignment
by Dmitrij Pochepko 11 Dec '18

11 Dec '18

Hi, please review small patch for 8205421 - AARCH64: StubCodeMark should be placed after alignment This patch moves few StubCodeMark declarations after alignment code to have no alignment "nop" instructions in stub listing (like -XX:+PrintStubCode) CR: https://bugs.openjdk.java.net/browse/JDK-8205421 webrev: http://cr.openjdk.java.net/~dpochepk/8205421/webrev.01/ Testing: I checked patched build output via -XX:+PrintStubCode. Thanks, Dmitrij

3 3

RFR: 8189107 - AARCH64: create intrinsic for pow
by Dmitrij Pochepko 21 Nov '18

21 Nov '18

Hi all, please review patch for 8189107 - AARCH64: create intrinsic for pow This patch implements Math.pow intrinsic using same algorithm as original libm. There are few optimizations: - polynomial calculations are vectorized where possible - branches are organized to have shorter execution path for non-corner-case values - FP constants are loaded from separate tables (mostly loaded in vector form) - instructions are organized to reduce register dependencies and also to have FP loads in parallel with ALU instruction where possible Benchmarks: I created benchmark to measure Math.pow: http://cr.openjdk.java.net/~dpochepk/8189107/MathBench.java Improvement per platform (rounded): ThunderX2: 26% ThunderX: 10% Cortex A53: 22% Cortex A72: 24% Detailed results table is here: http://cr.openjdk.java.net/~dpochepk/8189107/math.pow.xls This patch depends on 8209439: C2 library_call can potentially ignore Math.pow intrinsic or use null pointer webrev: http://cr.openjdk.java.net/~dpochepk/8189107/webrev.01/ CR: https://bugs.openjdk.java.net/browse/JDK-8189107 Testing: I ran jtreg test for pow and pow JCK tests. All passed. Thanks, Dmitrij

3 26

RFR: 8213204 - ReservedStackTest and ReservedStackTestCompiler tests fail on windows
by Bob Vandette 31 Oct '18

31 Oct '18

Please review this test fix that solve a problem with a regression that was introduced with the changes done to remove one of the AARCH64 ports (https://bugs.openjdk.java.net/browse/JDK-8209093) BUG: https://bugs.openjdk.java.net/browse/JDK-8213204 WEBREV: http://cr.openjdk.java.net/~bobv/8213204/webrev Here is the effective change that I should have done to this test when removing the Hybrid arm64 port. diff --git a/test/hotspot/jtreg/runtime/ReservedStack/ReservedStackTest.java b/test/hotspot/jtreg/runtime/ReservedStack/ReservedStackTest.java --- a/test/hotspot/jtreg/runtime/ReservedStack/ReservedStackTest.java +++ b/test/hotspot/jtreg/runtime/ReservedStack/ReservedStackTest.java @@ -233,19 +233,16 @@ } private static boolean isAlwaysSupportedPlatform() { - // Note: To date Aarch64 is the only platform that we don't statically - // know if it supports the reserved stack area. This is because the - // open Aarch64 port supports it and the Oracle arm64 port does not. return Platform.isAix() || (Platform.isLinux() && (Platform.isPPC() || Platform.isS390x() || Platform.isX64() || - Platform.isX86())) || + Platform.isX86() || Platform.isAArch64())) || Platform.isOSX() || Platform.isSolaris(); } private static boolean isNeverSupportedPlatform() { - return !isAlwaysSupportedPlatform() && !Platform.isAArch64(); + return !isAlwaysSupportedPlatform(); } private static boolean isSupportedPlatform; Bob.

3 2

JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64
by ci_notify＠linaro.org 31 Oct '18

31 Oct '18

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/jdkX/openjdk-jtreg-nightly-tests/summary/2018/302… ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/22 pass: 5,790; fail: 18; not run: 90 Build 1: aarch64/2018/oct/29 pass: 5,789; fail: 19; not run: 90 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/22 pass: 8,497; fail: 685; error: 29 Build 1: aarch64/2018/oct/29 pass: 8,538; fail: 653; error: 25 ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/22 pass: 3,971; fail: 5 Build 1: aarch64/2018/oct/29 pass: 3,972; fail: 5 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 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): 7.71x Relative performance: Server critical-jOPS (nc): 8.43x 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 server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 204.57 Server 204.57 / Server 2014-04-01 (71.00): 2.88x 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 10 days. 2018-10-23 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/295/results/ 2018-10-30 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/302/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: 8209093 - JEP 340: One AArch64 Port, Not Two
by David Holmes 30 Oct '18

30 Oct '18

Hi Bob, On 18/09/2018 2:20 AM, Bob Vandette wrote: > Please review the changes related to JEP 340 which remove the second 64-bit ARM port > from the JDK. > > http://cr.openjdk.java.net/~bobv/8209093/webrev.01 > > I’ve testing building the remaining 32 and 64 bit ARM ports including the minimal, client and server VMs. > I’ve run specJVM98 on the three 32-bit ARM VMs. Did you test all the ARM related abi-profiles? It seems to me they were only for Oracle's ARM32 port and may have never been used otherwise. I would have expected all that stuff to be removed. Cheers, David > I also verified that Linux x64 builds. > > Bob. > >

3 6

RFR(XS): 8211320: Aarch64: unsafe.compareAndSetByte() and unsafe.compareAndSetShort() c2 intrinsics broken with negative expected value
by Roland Westrelin 24 Oct '18

24 Oct '18

http://cr.openjdk.java.net/~roland/8211320/webrev.00/ Intrinsics for unsafe.compareAndSetByte() and unsafe.compareAndSetShort() don't properly deal with sign extension: load exclusive doesn't sign extend loaded value but comparison is done with sign extended value. Roland.

3 18

SIGBUS on linux/aarch64 serviceability test HS202 - JDK-8209415
by gary.adams＠oracle.com 24 Oct '18

24 Oct '18

A bug was reported for the HS202 serviceability test on a linux/aarch64 platform, but there have been no failures reported on other platforms. I'm afraid it will get lost if it is not properly labeled. Is there anyone who could confirm the problem still exists on the latest linux/aarch64 builds? Does the error look familiar? https://bugs.openjdk.java.net/browse/JDK-8209415

2 1