July 2020 - aarch64-port-dev

8248238: Implementation of JEP: Windows AArch64 Support
by Bernhard Urban-Forster 14 Sep '20

14 Sep '20

Hi all, please consider importing the following changeset into `aarch64-port/jdk-windows`. JBS: https://bugs.openjdk.java.net/browse/JDK-8248238 Webrev: https://cr.openjdk.java.net/~burban/8248238 Thank you, Monica, Ludovic and Bernhard

5 20

RFR(L): 8231441: AArch64: Initial SVE backend support
by Ningsheng Jian 03 Sep '20

03 Sep '20

Hi, Could you please help to review this patch adding AArch64 SVE support? It also touches c2 compiler shared code. Bug: https://bugs.openjdk.java.net/browse/JDK-8231441 Webrev: http://cr.openjdk.java.net/~njian/8231441/webrev.00 Arm has released new vector ISA extension for AArch64, SVE [1] and SVE2 [2]. This patch adds the initial SVE support in OpenJDK. In this patch we have: 1) SVE feature enablement and detection 2) SVE vector register allocation support with initial predicate register definition 3) SVE c2 backend for current SLP based vectorizer. (We also have a POC patch of a new vectorizer using SVE predicate-driven loop control, but that's still under development.) SVE register definition ======================= Unlike other SIMD architectures, SVE allows hardware implementations to choose a vector register length from 128 and 2048 bits, multiple of 128 bits. So we introduce a new vector type VectorA, i.e. length agnostic (scalable) vector type, and Op_VecA for machine vectora register. In the meantime, to minimize register allocation code changes, we also take advantage of one JIT compiler aspect, that is during the compile time we actually know the real hardware SVE vector register size of current running machine. So, the register allocator actually knows how many register slots an Op_VecA ideal reg requires, and could work fine without much modification. Since the bottom 128 bits are shared with the NEON, we extend current register mask definition of V0-V31 registers. Currently, c2 uses one bit mask for a 32-bit register slot, so to define at most 2048 bits we will need to add 64 slots in AD file. That's a really large number, and will also break current regmask assumption. Considering the SVE vector register is architecturally scalable for different sizes, we just define double of original NEON vector register slots, i.e. 8 slots: Vx, Vx_H, Vx_J ... Vx_O. After adlc, the generated register masks now looks like: const RegMask _VECTORA_REG_mask( 0x0, 0x0, 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff, ... const RegMask _VECTORD_REG_mask( 0x0, 0x0, 0x3030303, 0x3030303, 0x3030303, 0x3030303, 0x3030303, 0x3030303, ... const RegMask _VECTORX_REG_mask( 0x0, 0x0, 0xf0f0f0f, 0xf0f0f0f, 0xf0f0f0f, 0xf0f0f0f, 0xf0f0f0f, 0xf0f0f0f, ... And we use SlotsPerVecA to indicate regmask bit size for a VecA register. Although for physical register allocation, register allocator does not need to know the real VecA register size, while doing spill/unspill, current register allocation needs to know actual stack slot size to store/load VecA registers. SVE is able to do vector size agnostic spilling, but to minimize the code changes, as I mentioned before, we just let RA know the actual vector register size in current running machine, by calling scalable_vector_reg_size(). In the meantime, since some vector operations do not have unpredicated SVE1 instructions, but only predicate version, e.g. vector multiply, vector load/store. We have also defined predicate registers in this patch, and c2 register allocator will allocate a temp predicate register to fulfill the expecting unpredicated operations. And this can also be used for future predicate-driven vectorizer. This is not efficient for now, as we can see many ptrue instructions in the generated code. One possible solution I can see, is to block one predicate register, and preset it to all true. But to preserve/reinitialize a caller save register value cross calls seems risky to work in this patch. I decide to defer it to further optimization work. If anyone has any suggestions on this, I would appreciate. SVE feature detection ===================== Since we may have some compiled code based on the initial detected SVE vector register length and the compiled code is compiled only for that vector register length, we assume that the SVE vector register length will not be changed during the JVM lifetime. However, SVE vector length is per-thread and can be changed by system call [3], so we need to make sure that each jni call will not change the sve vector length. Currently, we verify the SVE vector register length on each JNI return, and if an SVE vector length change is detected, jvm simply reports error and stops running. The VM running vector length can also be set by existing VM option MaxVectorSize with c2 enabled. If MaxVectorSize is specified not the same as system default sve vector length (in /proc/sys/abi/sve_default_vector_length), JVM will set current process sve vector length to the specified vector length. Compiled code ============= We have added all current c2 backend codegen on par with NEON, but only for vector length larger than 128-bit. On a 1024 bit SVE environment, for the following simple loop with int array element type: for (int i = 0; i < LENGTH; i++) { c[i] = a[i] + b[i]; } c2 generated loop: 0x0000ffff811c0820: sbfiz x11, x10, #2, #32 0x0000ffff811c0824: add x13, x18, x11 0x0000ffff811c0828: add x14, x1, x11 0x0000ffff811c082c: add x13, x13, #0x10 0x0000ffff811c0830: add x14, x14, #0x10 0x0000ffff811c0834: add x11, x0, x11 0x0000ffff811c0838: add x11, x11, #0x10 0x0000ffff811c083c: ptrue p1.s // To be optimized 0x0000ffff811c0840: ld1w {z16.s}, p1/z, [x14] 0x0000ffff811c0844: ptrue p0.s 0x0000ffff811c0848: ld1w {z17.s}, p0/z, [x13] 0x0000ffff811c084c: add z16.s, z17.s, z16.s 0x0000ffff811c0850: ptrue p1.s 0x0000ffff811c0854: st1w {z16.s}, p1, [x11] 0x0000ffff811c0858: add w10, w10, #0x20 0x0000ffff811c085c: cmp w10, w12 0x0000ffff811c0860: b.lt 0x0000ffff811c0820 Test ==== Currently, we don't have real hardware to verify SVE features (and performance). But we have run jtreg tests with SVE in some emulators. On QEMU system emulator, which has SVE emulation support, jtreg tier1-3 passed with different vector sizes. We've also verified it with full jtreg tests without SVE on both x86 and AArch64, to make sure that there's no regression. The patch has also been applied to Vector API code base, and verified on emulator. In Vector API, there are more vector related tests and is more possible to generate vector instructions by intrinsification. A simple test can also run in QEMU user emulation, e.g. $ qemu-aarch64 -cpu max,sve-max-vq=2 java -XX:UseSVE=1 SIMD ( To run it in user emulation mode, we will need to bypass SVE feature detection code in this patch. E.g. apply: http://cr.openjdk.java.net/~njian/8231441/user-emulation.patch )l Others ====== Since this patch is a bit large, I've also split it into 3 parts, for easy review: 1) SVE feature detection http://cr.openjdk.java.net/~njian/8231441/webrev.00-feature 2) c2 registion allocation http://cr.openjdk.java.net/~njian/8231441/webrev.00-ra 3) SVE c2 backend http://cr.openjdk.java.net/~njian/8231441/webrev.00-c2 Part of this patch has been contributed by Joshua Zhu and Yang Zhang. Refs ==== [1] https://developer.arm.com/docs/ddi0584/latest [2] https://developer.arm.com/docs/ddi0602/latest [3] https://www.kernel.org/doc/Documentation/arm64/sve.txt Thanks, Ningsheng

9 59

Re: [aarch64-port-dev ] RFR: 8165404: AArch64: Implement SHA512 accelerator/intrinsic
by Yangfei (Felix) 19 Aug '20

19 Aug '20

Ping... Any suggestions? Thanks, Felix > -----Original Message----- > From: Yangfei (Felix) > Sent: Saturday, July 25, 2020 10:16 AM > To: hotspot-runtime-dev(a)openjdk.java.net > Cc: aarch64-port-dev(a)openjdk.java.net > Subject: RFR: 8165404: AArch64: Implement SHA512 accelerator/intrinsic > > Hi, > > Bug: https://bugs.openjdk.java.net/browse/JDK-8165404 > Webrev: http://cr.openjdk.java.net/~fyang/8165404/webrev.00/ > > This implement SHA-384/SHA-512 transformation using aarch64 v8.2 > SHA512 Crypto Extensions. > Reference implementation: > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/… > m64/crypto/sha512-ce-core.S?h=v5.4.52 > > We used QEMU system emulator which supports SHA512 instructions to > test the functionality. > SHA512 basic functionality is tested with: > http://cr.openjdk.java.net/~fyang/8165404/SHA512.java > Patch passed jtreg tier1-3 test with QEMU system emulator. > We've also verified it with full jtreg tests without SHA512 instructions on > aarch64-linux-gnu, to make sure that there's no regression. > > We've also created a JMH for performance test: > http://cr.openjdk.java.net/~fyang/8165404/TestSHA512.java > We measured the performance benefit with a cycle-accurate simulator. > Patch delivers more than 2x performance gain measured with the three > different size message. > > Comments? > > Thanks, > Felix

2 15

RFR(XS) 8248816: C1: Fix signature conflict in LIRGenerator::strength_reduce_multiply
by Bernhard Urban-Forster 13 Aug '20

13 Aug '20

Hi all, this is a small fixup: the declaration of `strength_reduce_multiply` uses a `jint` for the parameter `constant` [1], but some backends were using `int` instead. JBS: https://bugs.openjdk.java.net/browse/JDK-8248816 Webrev: http://cr.openjdk.java.net/~burban/8248816/ Thank you, -Bernhard [1] https://hg.openjdk.java.net/jdk/jdk/file/8f7ede592c28/src/hotspot/share/c1/…

3 4

RFR/Feedback(S) 8248663: AArch64: Avoid existing macros/keywords of MSVC
by Monica Beckwith 04 Aug '20

04 Aug '20

These changes are concerning specific macro names or keywords used by MSVC. E.g. `mvn,` `DIFFERENCE` and `far.` We are proposing to change those in the shared code. JBS: https://bugs.openjdk.java.net/browse/JDK-8248663 Webrev: https://cr.openjdk.java.net/~mbeckwit/8248663/webrev.00/ Thanks, Monica

4 8

RFR[XXS] 8248672: utilities: Introduce DEPRECATED macro for GCC and MSVC
by Ludovic Henry 04 Aug '20

04 Aug '20

Hi, Could I please have a review on the following. It simply adds the `DEPRECATED` macro to wrap `__attribute__ ((deprecated))` for GCC, and the equivalent for MSVC. JBS: https://bugs.openjdk.java.net/browse/JDK-8248672 Webrev: http://cr.openjdk.java.net/~burban/luhenry/8248672/webrev.00 Thank you, -- Ludovic

4 13

RFR(XXS) 8250824: AArch64: follow up for JDK-8248414
by Bernhard Urban-Forster 03 Aug '20

03 Aug '20

Hi all, the original change [1] missed to update an assert. JBS: https://bugs.openjdk.java.net/browse/JDK-8250824 Webrev: http://cr.openjdk.java.net/~burban/8250824/ Thank you, -Bernhard [1] https://hg.openjdk.java.net/jdk/jdk/rev/d352e5db468c

2 2

8u-aarch64: Backport 8161072: AArch64: jtreg compiler/uncommontrap/TestDeoptOOM failure
by Yangfei (Felix) 03 Aug '20

03 Aug '20

Hi, I am seeing the same test failure with a 8u-aarch64 fastdebug build. Not sure if this bug has been evaluated for 8u-aarch64 backport. Bug: https://bugs.openjdk.java.net/browse/JDK-8161072 Webrev: http://cr.openjdk.java.net/~fyang/8161072-8u/webrev.00/ Performed full jtreg test with a 8u-aarch64 fastdebug build. The affected test fail without the patch and pass otherwise. OK to backport? Thanks, Felix

2 4

hg: aarch64-port/jdk8u-shenandoah/hotspot: 6 new changesets
by gnu.andrew＠redhat.com 31 Jul '20

31 Jul '20

Changeset: bace48b16628 Author: andrew Date: 2020-07-14 17:23 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/bace4… Added tag jdk8u262-ga for changeset 1c6e1f187fdc ! .hgtags Changeset: 3bd5ac4488a3 Author: andrew Date: 2020-07-24 22:41 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/3bd5a… Added tag jdk8u265-b00 for changeset 1c6e1f187fdc ! .hgtags Changeset: 5fd1f66f27a4 Author: andrew Date: 2020-07-24 22:42 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/5fd1f… Added tag jdk8u265-b01 for changeset 3bd5ac4488a3 ! .hgtags Changeset: 091ec2e29881 Author: andrew Date: 2020-07-27 01:20 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/091ec… Merge jdk8u265-b01 ! .hgtags Changeset: 86ec9f66c77c Author: andrew Date: 2020-07-27 01:21 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/86ec9… Added tag aarch64-shenandoah-jdk8u265-b01 for changeset 091ec2e29881 ! .hgtags Changeset: 19f650cbb25b Author: andrew Date: 2020-07-31 20:51 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/19f65… Merge

1 0

hg: aarch64-port/jdk8u-shenandoah/jdk: 7 new changesets
by gnu.andrew＠redhat.com 31 Jul '20

31 Jul '20

Changeset: d6ba796b8c9f Author: andrew Date: 2020-07-14 17:23 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/d6ba796b8… Added tag jdk8u262-ga for changeset 66699ff7f013 ! .hgtags Changeset: 1a6df78fe390 Author: andrew Date: 2020-07-24 16:59 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/1a6df78fe… 8249677: Regression in 8u after JDK-8237117: Better ForkJoinPool behavior Summary: Avoid altering the behaviour of the protected ForkJoinWorkerThread(ForkJoinPool) constructor Reviewed-by: andrew, mbalao Contributed-by: Anton Kozlov <akozlov(a)azul.com> ! src/share/classes/java/util/concurrent/ForkJoinPool.java ! src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java + test/java/util/concurrent/forkjoin/AccessControlContext.java + test/java/util/concurrent/forkjoin/AccessControlContext.policy Changeset: 323008dfe93e Author: andrew Date: 2020-07-24 22:31 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/323008dfe… 8250546: Expect changed behaviour reported in JDK-8249846 Reviewed-by: mbalao ! test/java/util/concurrent/forkjoin/AccessControlContext.java Changeset: 9204e03217f7 Author: andrew Date: 2020-07-24 22:41 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/9204e0321… Added tag jdk8u265-b00 for changeset 66699ff7f013 ! .hgtags Changeset: 656ef8101df7 Author: andrew Date: 2020-07-24 22:42 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/656ef8101… Added tag jdk8u265-b01 for changeset 9204e03217f7 ! .hgtags Changeset: 03a7cddeb256 Author: andrew Date: 2020-07-27 01:20 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/03a7cddeb… Merge jdk8u265-b01 ! .hgtags ! src/share/classes/java/util/concurrent/ForkJoinPool.java Changeset: 164cd43a1739 Author: andrew Date: 2020-07-27 01:21 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/164cd43a1… Added tag aarch64-shenandoah-jdk8u265-b01 for changeset 03a7cddeb256 ! .hgtags

1 0