March 2020 - aarch64-port-dev

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

RFR: 8216557 Aarch64: Add support for Concurrent Class Unloading
by Stuart Monteith 29 Apr '20

29 Apr '20

Hello, Please review this change to implement nmethod entry barriers on aarch64, and hence concurrent class unloading with ZGC. Shenandoah will need to be separately tested and enabled - there are problems with this on Shenandoah. It has been tested with JTreg, runs with SPECjbb, gcbench, and Lucene as well as Netbeans. In terms of interesting features: With nmethod entry barriers, immediate oops are removed by: LIR_Assembler::jobject2reg and MacroAssembler::movoop This is to ensure consistency with the entry barrier, as otherwise with an immediate we'd otherwise need an ISB. I've added "-XX:DeoptNMethodBarrierALot". I found this functionality useful in testing as deoptimisation is very infrequent. I've written it as an atomic to avoid it happening too frequently. As it is a new option, I'm not sure whether any more is needed than this review. A new test has been added "test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherDeoptWithZ.java" to test GC with that option enabled. BarrierSetAssembler::nmethod_entry_barrier This method emits the barrier code. In internal review it was suggested the "dmb( ISHLD )" should be replaced by "membar(LoadLoad)". I've not done this as the BarrierSetNMethod code checks the exact instruction sequence, and I prefer to be explicit. Benchmarking method entry shows an increase of around 6ns with the nmethod entry barrier. The deoptimisation code was contributed by Andrew Haley. The bug: https://bugs.openjdk.java.net/browse/JDK-8216557 The webrev: http://cr.openjdk.java.net/~smonteith/8216557/webrev.0/ BR, Stuart IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

7 21

RFR(S): 8241475: AArch64: Add missing support for PopCountVI node
by Pengfei Li 03 Apr '20

03 Apr '20

Hi, Please help review this another missing node support for AArch64. JBS: https://bugs.openjdk.java.net/browse/JDK-8241475 Webrev: http://cr.openjdk.java.net/~pli/rfr/8241475/webrev.01/ This adds missing support for C2 node "PopCountVI" for AArch64. This node is now used on x86 and ppc for the codegen of vectorized bit count of multiple lanes of ints. In this AArch64 implementation, CNT instruction is used firstly to get a per-byte bit count of the NEON register. Then two UADDLP instructions are used to convert the per-byte counts to per-int counts. [TESTS] Jtreg: hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1. No new failure found. Intel has already contributed a jtreg case in the x86 patch [1] for this. JMH: Tested with a small JMH [2] Before: Benchmark Mode Cnt Score Error Units TestPopCount.testPopCount avgt 15 129.773 ± 36.120 us/op After: Benchmark Mode Cnt Score Error Units TestPopCount.testPopCount avgt 15 41.830 ± 0.068 us/op Thanks Dmitrij for the suggestion on this patch. [1] http://hg.openjdk.java.net/jdk/jdk/rev/b242a1e3f9cf [2] http://cr.openjdk.java.net/~pli/rfr/8241475/TestPopCount.java -- Thanks, Pengfei

4 10

Question about JVM option "-XX:+UseBarriersForVolatile" usage in aarch64.
by Xiaohong Gong 03 Apr '20

03 Apr '20

Hi, Recently we met the Renassiance benchmark hang issue on AArch64 when running with VM option "-XX:+UseBarriersForVolatile". We noticed that it should be the same memory sequentially consistent issue mentioned in JDK-8179954<https://bugs.openjdk.java.net/browse/JDK-8179954> which is caused by mixed using "LDR, DMB ISHLD" for java volatile load and "STLR/STLXR" for volatile store. JDK-8179954 resolved it by inserting a full barrier before the volatile load in C1/Interpreter. However it only happens with the VM option "UseBarriersForVolatile" closed, because C2 only uses "LDAR/STLR" to implement the volatile access under it. Here is a part of the fixing codes in Interpreter: if (! UseBarriersForVolatile) { Label notVolatile; __ tbz(raw_flags, ConstantPoolCacheEntry::is_volatile_shift, notVolatile); __ membar(MacroAssembler::AnyAny); __ bind(notVolatile); } However, there are also some other places that use "STLR/STLXR" in hotspot when "UseBarriersForVolatile" is true, like monitor and atomics. For atomics like CAS, they do not have a trailing "STORE_LOAD" barrier with "-XX:+UseBarriersForVolatile". This might have the memory consistent issue if there is a subsequent volatile load ("LDR, DMB ISHLD"). Here is the codes generated for CAS by C2 with "-XX:+UseBarriersForVolatile": dmb ish retry: ldxr w0, [address] cmp w0, w1 b.ne done stlxr w8, w2, [address] cbnz w8, retry done: dmb ishld // LOAD_LOAD | LOAD_STORE Without a STORE_LOAD barrier, the subsequent load could be float up before "stlxr" of the CAS. This might expected not to happen if the load is a volatile one. So my question is: what does the main usage of the option "-XX:+UseBarriersForVolatile" in real applications? Do we need to concern the issues with it? If we do, so maybe the issue is valuable to be fixed. I also created a JBS here: https://bugs.openjdk.java.net/browse/JDK-8241137. Thanks, Xiaohong Gong

5 10

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

31 Mar '20

Changeset: 00eaaa430a54 Author: andrew Date: 2020-03-20 14:26 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/00eaa… Added tag jdk8u252-b07 for changeset d17814ea88e3 ! .hgtags Changeset: 9f9d7938db16 Author: andrew Date: 2020-03-23 21:33 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/9f9d7… Merge jdk8u252-b07 ! .hgtags Changeset: 032c004c0b23 Author: andrew Date: 2020-03-23 21:35 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/032c0… Added tag aarch64-shenandoah-jdk8u252-b07 for changeset 9f9d7938db16 ! .hgtags

1 0

hg: aarch64-port/jdk8u-shenandoah/nashorn: 3 new changesets
by gnu.andrew＠redhat.com 31 Mar '20

31 Mar '20

Changeset: 95d61d0f326b Author: andrew Date: 2020-03-20 14:26 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/95d61… Added tag jdk8u252-b07 for changeset 0666ec7fe2b4 ! .hgtags Changeset: cbbbe5b13332 Author: andrew Date: 2020-03-23 21:33 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/cbbbe… Merge jdk8u252-b07 ! .hgtags Changeset: 62c5e270b91d Author: andrew Date: 2020-03-23 21:35 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/62c5e… Added tag aarch64-shenandoah-jdk8u252-b07 for changeset cbbbe5b13332 ! .hgtags

1 0

hg: aarch64-port/jdk8u-shenandoah/corba: 3 new changesets
by gnu.andrew＠redhat.com 31 Mar '20

31 Mar '20

Changeset: 63738d15bb7f Author: andrew Date: 2020-03-20 14:26 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/63738d1… Added tag jdk8u252-b07 for changeset ee99eeee44ad ! .hgtags Changeset: cb7514c874ee Author: andrew Date: 2020-03-23 21:33 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/cb7514c… Merge jdk8u252-b07 ! .hgtags Changeset: 8bb2bcdd74ab Author: andrew Date: 2020-03-23 21:34 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/8bb2bcd… Added tag aarch64-shenandoah-jdk8u252-b07 for changeset cb7514c874ee ! .hgtags

1 0

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

31 Mar '20

Changeset: 72a6d93679e5 Author: andrew Date: 2020-03-20 14:25 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/72a6d93679e5 Added tag jdk8u252-b07 for changeset 746815de8b5b ! .hgtags Changeset: 57a11875546a Author: andrew Date: 2020-03-23 21:33 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/57a11875546a Merge jdk8u252-b07 ! .hgtags Changeset: 72d8c6c077e1 Author: andrew Date: 2020-03-23 21:34 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/72d8c6c077e1 Added tag aarch64-shenandoah-jdk8u252-b07 for changeset 57a11875546a ! .hgtags

1 0

Re: [aarch64-port-dev ] Question about JVM option "-XX:+UseBarriersForVolatile" usage in aarch64.
by Derek White 30 Mar '20

30 Mar '20

I think that was us (a bit before my time!). I'll double-check if that variant ever made it out... - Derek -----Original Message----- From: aarch64-port-dev <aarch64-port-dev-bounces(a)openjdk.java.net> On Behalf Of Andrew Haley Sent: Monday, March 30, 2020 6:44 AM To: Nick Gasson <nick.gasson(a)arm.com>; aarch64-port-dev(a)openjdk.java.net Cc: nd <nd(a)arm.com>; Xiaohong Gong <Xiaohong.Gong(a)arm.com> Subject: Re: [aarch64-port-dev ] Question about JVM option "-XX:+UseBarriersForVolatile" usage in aarch64. ---------------------------------------------------------------------- On 3/30/20 11:13 AM, Nick Gasson wrote: > There is this one use in vm_version_aarch64.cpp: > > if (FLAG_IS_DEFAULT(UseBarriersForVolatile)) { > UseBarriersForVolatile = (_features & CPU_DMB_ATOMICS) != 0; > } > > CPU_DMB_ATOMICS is set for one particular variant of one vendor's CPU. > It came from "8079203: aarch64: need to cater for different partner > implementations". But I can't find any explanation as to why it's > required. Any ideas? CPU errata? > > https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java. > net_pipermail_aarch64-2Dport-2Ddev_2015-2DMay_002315.html&d=DwIF-g&c=n > KjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m= > dY4p0rOQhLXVe5xRZZlJ8GqVaDTZuBaQrt_nb8fBMKA&s=Uh_9IoXOwz8i9My-P1YeUPZm > TkPUoQUenIVVvmoAIPw&e= I remember an early stepping where STLR/LDAR weren't sequentially consistent, so it was necessary to generate explicit DMBs. I doubt that parts with this bug ever reached the market. Having said that, maybe someone is still using one. It might be worth correcting UseBarriersForVolatile and making the flag diagnostic only. Having said that, the entire C library uses these instructions. Opinions? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com&d=DwIF-… > https://urldefense.proofpoint.com/v2/url?u=https-3A__keybase.io_andrewhaley… EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

1 0

[15] RFR 8241765: Shenandoah: AARCH64 need to save/restore call clobbered registers before calling keepalive barrier
by Zhengyu Gu 28 Mar '20

28 Mar '20

This bug was discovered while testing aarch64 nmethod entry barrier patch posted by Stuart Monteith [1]. We had the same issues on x86 platforms, and fixed by JDK-8233500 and JDK-8237776, but never fixed aarch64. Bug: https://bugs.openjdk.java.net/browse/JDK-8241765 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8241765/webrev.00/ Test: hotspot_gc_shenandoah Thanks, -Zhengyu [1] https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-March/028998.ht…

3 2