September 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

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

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): 8211207: AArch64: Fix build failure after JDK-8211029
by Pengfei Li (Arm Technology China) 01 Oct '18

01 Oct '18

Hi, The commit "8211029: Have a common set of enabled warnings for all native libraries" breaks AArch64 build. We have several code warnings in AArch64 C1 and template table. And options "-Werror=c++11-compat" and "-Werror=switch" are turned on by this commit. Error log can be found at JBS: https://bugs.openjdk.java.net/browse/JDK-8211207 Please help review this patch that fixed these warnings in AArch64 backend. webrev: http://cr.openjdk.java.net/~njian/8211207/webrev.00/ -- Thanks, Pengfei

5 12

hg: aarch64-port/jdk8u/hotspot: 8207838: AArch64: Float registers incorrectly restored in JNI call
by felix.yang＠linaro.org 29 Sep '18

29 Sep '18

Changeset: f046cf1847b8 Author: fyang Date: 2018-09-28 08:48 +0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/hotspot/rev/f046cf1847b8 8207838: AArch64: Float registers incorrectly restored in JNI call Summary: fix the order in which float registers are restored in restore_args for aarch64 Reviewed-by: aph Contributed-by: guoge1(a)huawei.com ! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp + test/compiler/floatingpoint/8165673/TestFloatJNIArgs.java + test/compiler/floatingpoint/8165673/TestFloatJNIArgs.sh + test/compiler/floatingpoint/8165673/libTestFloatJNIArgs.c + test/compiler/floatingpoint/8207838/TestFloatSyncJNIArgs.java + test/compiler/floatingpoint/8207838/TestFloatSyncJNIArgs.sh + test/compiler/floatingpoint/8207838/libTestFloatSyncJNIArgs.c - test/compiler/floatingpoint/TestFloatJNIArgs.java - test/compiler/floatingpoint/TestFloatJNIArgs.sh - test/compiler/floatingpoint/libTestFloatJNIArgs.c

1 0

RFR: Backport patch for 8207838 to aarch64/jdk8u
by Yangfei (Felix) 29 Sep '18

29 Sep '18

Hi, I see the same issue (8207838) for aarch64/jdk8u repo, and I am trying to backport this patch: ---------------------------------------------------------------- 8207838: AArch64: Float registers incorrectly restored in JNI call Summary: fix the order in which float registers are restored in restore_args for aarch64 Reviewed-by: aph Contributed-by: guoge1(a)huawei.com --------------------------------------------------------------- The original jdk11 patch, which is merged more than a month ago: http://hg.openjdk.java.net/jdk/jdk11/rev/3b3685479784 The backport patch with some adaptations for the test case: http://cr.openjdk.java.net/~fyang/8207838-backport/webrev.00/ Tested with Jtreg hotspot & langtools with an aarch64 server build. OK to backport? Thanks for your help, Felix

2 1

OpenJDK on AArch64 Fireside chat
by Stuart Monteith 28 Sep '18

28 Sep '18

Hello, It is has been a while since there has been a "Fireside chat" for those of us working on AArch64. To accommodate those on the West coast of the USA and Europe, I suggest 15:00 UTC, which is 8am in PDT, 4pm in UK, 6pm in Europe. Please let me know what day will suit you and whether the time is acceptable. Thanks, Stuart

3 3

RFR(S): 8210413: AArch64: Optimize div/rem by constant in C1
by Pengfei Li (Arm Technology China) 26 Sep '18

26 Sep '18

Hi, Could you please help review this optimization in C1 AArch64? Currently, there are 2 LIR_Assembler::arithmetic_idiv() methods in c1_LIRAssembler_aarch64.cpp. One is left unimplemented, the other checks whether the divisor is a power-of-2 constant but does nothing optimized then. In this patch, I combined these 2 methods and added 2 below optimizations for integer div/rem. 1) Remove the div-by-zero check if the divisor is known to be a non-zero constant. 2) Use cheaper instructions instead of "sdiv" to do div/rem by a power-of-2 constant (including 1, 2, 4, 8, 16, ...) JBS: https://bugs.openjdk.java.net/browse/JDK-8210413 webrev: http://cr.openjdk.java.net/~njian/8210413/webrev.00/ As Roman Kennke's original code comment said, using the temp register passed into arithmetic_idiv() is problematic. So I also use the rscratch1 directly for intermediate result in div/rem calculations. You could refer thread http://mail.openjdk.java.net/pipermail/aarch64-port-dev/2018-September/0063… for this issue. I've run jtreg full test with this patch and JVM option "-XX:TieredStopAtLevel=1" on an AArch64 server and no new issues found. -- Thanks, Pengfei

3 6

Re: [aarch64-port-dev ] RFR: 8209093 - JEP 340: One AArch64 Port, Not Two
by Vladimir Kozlov 24 Sep '18

24 Sep '18

CCing to build-dev and aarch64-port. I looked through changes and they seem fine. Thanks, Vladimir On 9/17/18 9: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. > > I also verified that Linux x64 builds. > > Bob. > >

6 6