June 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 (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes
by Yang Zhang 30 Jul '20

30 Jul '20

Hi, Following up on review requests of API [0], Java implementation and test [1], General Hotspot changes[2] for Vector API and x86 backend changes [3]. Here's a request for review of AArch64 backend changes required for supporting the Vector API: JEP: https://openjdk.java.net/jeps/338 JBS: https://bugs.openjdk.java.net/browse/JDK-8223347 Webrev: http://cr.openjdk.java.net/~yzhang/vectorapi/vectorapi.rfr/aarch64_webrev/w… Complete implementation resides in vector-unstable branch of panama/dev repository [4]. Looking forward to your feedback. Best Regards, Yang [0] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065345.html [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-April/065587.html [2] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-April/037… [3] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-April/037… [4] https://openjdk.java.net/projects/panama/ $ hg clone http://hg.openjdk.java.net/panama/dev/ -b vector-unstable

7 21

RFR(XS): 8248219: aarch64: missing memory barrier in fast_storefield and fast_accessfield
by Yangfei (Felix) 08 Jul '20

08 Jul '20

Hi, Bug: https://bugs.openjdk.java.net/browse/JDK-8248219 We were witnessing random JVM crash that triggers about 2 or 3 times each day in one of our production environment. Debugging show this is triggered after patching bytecode. Normal template interpreter sequence: TemplateTable::putfield_or_static -> TemplateTable::resolve_cache_and_index -> InterpreterRuntime::resolve_from_cache -> InterpreterRuntime::resolve_get_put cpCache entry is updated after that. Then we do bytecode patching in TemplateTable::putfield_or_static and dispatch to the next bytecode through InterpreterMacroAssembler::dispatch_next. 510 void InterpreterMacroAssembler::dispatch_next(TosState state, int step, bool generate_poll) { 511 // load next bytecode 512 ldrb(rscratch1, Address(pre(rbcp, step))); 513 dispatch_base(state, Interpreter::dispatch_table(state), generate_poll); 514 } After that we switch to the fast path: TemplateTable::fast_storefield. This will read the cpCache entry. But we may have invalid cpCache entry values as the memory barrier is missing. The bytecode load may be scheduled before the bytecode load and even before the setting of the cpCache entry. Reference: armv8 architecture reference manual K11.6.1 This restriction applies only when the data value returned by a read is used as a data value to calculate the address of a subsequent read or write. It does not apply if the data value returned by a read determines the condition flags values, and the values of the flags are used for condition code evaluation to determine the address of a subsequent read, either through conditional execution or the evaluation of a branch. This is called a control dependency. One fix adding explicit memory barriers looks like: diff -r abdc7ca79bdf src/hotspot/cpu/aarch64/templateTable_aarch64.cpp --- a/src/hotspot/cpu/aarch64/templateTable_aarch64.cpp Tue Jun 23 13:41:55 2020 +0300 +++ b/src/hotspot/cpu/aarch64/templateTable_aarch64.cpp Wed Jun 24 15:01:21 2020 +0800 @@ -2975,6 +2975,9 @@ // access constant pool cache __ get_cache_and_index_at_bcp(r2, r1, 1); + // Must prevent reordering of the following cp cache loads with bytecode load + __ membar(MacroAssembler::LoadLoad); + // test for volatile with r3 __ ldrw(r3, Address(r2, in_bytes(base + ConstantPoolCacheEntry::flags_offset()))); @@ -3067,6 +3070,10 @@ // access constant pool cache __ get_cache_and_index_at_bcp(r2, r1, 1); + + // Must prevent reordering of the following cp cache loads with bytecode load + __ membar(MacroAssembler::LoadLoad); + __ ldr(r1, Address(r2, in_bytes(ConstantPoolCache::base_offset() + ConstantPoolCacheEntry::f2_offset()))); __ ldrw(r3, Address(r2, in_bytes(ConstantPoolCache::base_offset() + Another approach avoids the memory barrier by introducing artificial true dependency: --- a/src/hotspot/cpu/aarch64/templateTable_aarch64.cpp Tue Jun 23 13:41:55 2020 +0300 +++ b/src/hotspot/cpu/aarch64/templateTable_aarch64.cpp Wed Jun 24 15:43:49 2020 +0800 @@ -2975,6 +2975,11 @@ // access constant pool cache __ get_cache_and_index_at_bcp(r2, r1, 1); + // use artificial data dependency from the bytecode load to the following + // cp cache loads to avoid a load-load barrier + __ eor(rscratch2, rscratch1, rscratch1); + __ orr(r2, r2, rscratch2); + // test for volatile with r3 __ ldrw(r3, Address(r2, in_bytes(base + ConstantPoolCacheEntry::flags_offset()))); @@ -3067,6 +3072,12 @@ // access constant pool cache __ get_cache_and_index_at_bcp(r2, r1, 1); + + // use artificial data dependency from the bytecode load to the following + // cp cache loads to avoid a load-load barrier + __ eor(rscratch2, rscratch1, rscratch1); + __ orr(r2, r2, rscratch2); + __ ldr(r1, Address(r2, in_bytes(ConstantPoolCache::base_offset() + ConstantPoolCacheEntry::f2_offset()))); __ ldrw(r3, Address(r2, in_bytes(ConstantPoolCache::base_offset() + Suggenstions? Thanks, Felix

5 16

OpenJDK extension to AArch64 and Windows
by Monica Beckwith 07 Jul '20

07 Jul '20

Hello OpenJDK community, As the project lead here @Microsoft, I am pleased to share that we have been working towards a Windows addition to the OpenJDK AArch64 port. We are very thankful to all that have contributed to the Linux+aarch64 and Windows+x86-64. Both these codebases came to our rescue on numerous occasions. Support status: We have successfully ported C2 and can build the server release (cross-compiled environment) Test coverage: C2 + ParallelGC (No AOT, JVMCI, ZGC, ShenandoahGC, G1GC) Tests and benchmarks covered [1]: JTReg [2], JCStress, jmh-jdk-microbenchmarks, SPEC SERT, SPECJBB2015 [3], SPEC JVM2008, Scimark2, SPEC JBB2005. Umbrella Bug ID: https://bugs.openjdk.java.net/browse/JDK-8248238 Webrevs: `Webrev P1`: http://cr.openjdk.java.net/~burban/winarm64_p1_llp64/ & `Webrev P2`: http://cr.openjdk.java.net/~burban/winarm64_p2_new-target/ The first patch `Webrev P1` (patch 1 aka P1 in our tests) helps integrate support for Windows (LLP64) on Linux + AArch64 The second patch `Webrev P2` (patch 2 aka P2 in our tests) adds the 'windows-aarch64' support in `os_cpu`. We also had to modify shared code, and I am highlighting a few details here: * In windows_x86 such as the `get_frame_at_stack_banging_point` in `os_windows_x86.cpp`, * In `os/windows os_windows.cpp` to make it aware of Windows + Arm64 * `os/windows` in `threadCritical_windows.cpp`, * Windbg support * `globalDefinitions_visCPP.hpp` in `share/utilities` * We also added Vectored Exception Handling (VEH) to P2, as it is a requirement on Windows + Arm64 (due to ABI specifications). Also, in `Webrev P2`, you will find that we have made some significant changes to `cpu/aarch64` around register usage since on Windows + Arm64, register R18 points to TEB [4]. We have discussed this with Andrew Haley and Andrew Dinn, and they are helping us with a cleaner implementation of the same. Their constant support and guidance have humbled me. I'd also like to recognize the great work done by Ludovic Henry (our resident runtime expert) in driving the C2 support and by Bernhard Urban-Forster, (who recently joined our team) in helping expand the coverage to G1 GC. As a part of this project, we have also worked on two additional patches: * Expanding VEH on Windows to x86-64 (patch 3 aka P3 in our tests). Details here: https://bugs.openjdk.java.net/browse/JDK-8247941 * Improvements in the shared cross-platform code on Windows (patch 4 aka P4 in our tests) - We will send out a separate patch soon. We welcome any feedback and comments from the community and are looking forward to working together. Regards, Monica [1] https://github.com/microsoft/openjdk-aarch64/blob/master/wkload-status-on-W… [2] https://github.com/microsoft/openjdk-aarch64/blob/master/JTRegtests.md [3] https://github.com/microsoft/openjdk-aarch64/blob/master/SPECJBB2015-test-m… [4] https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?vi…

13 31

RFR: Shenandoah integration 2020-06-25
by Roman Kennke 30 Jun '20

30 Jun '20

I'd like to integrate 2 important backports from shenandoah/jdk8 to aarch64-port/jdk8u-shenandoah: http://cr.openjdk.java.net/~rkennke/aarch64-shenandoah-integration-2020-06-… It only touches Shenandoah code. Testing: several nightly runs of our CI, including hotspot_gc_shenandoah, specjvm, CTW tests and jcstress. Can I please get a review? Thanks, Roman

2 2

JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 13 on AArch64
by ci_notify＠linaro.org 28 Jun '20

28 Jun '20

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/jdk13/openjdk-jtreg-nightly-tests/summary/2020/17… ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/08 pass: 5,646; fail: 1 Build 1: aarch64/2019/aug/10 pass: 5,646; fail: 1 Build 2: aarch64/2019/nov/12 pass: 5,652 Build 3: aarch64/2019/nov/14 pass: 5,650; fail: 2 Build 4: aarch64/2019/nov/16 pass: 5,652 Build 5: aarch64/2019/dec/03 pass: 5,651; fail: 1 Build 6: aarch64/2019/dec/14 pass: 5,652 Build 7: aarch64/2020/jan/16 pass: 5,652 Build 8: aarch64/2020/may/28 pass: 5,669 Build 9: aarch64/2020/jun/02 pass: 5,677 Build 10: aarch64/2020/jun/09 pass: 5,691 Build 11: aarch64/2020/jun/18 pass: 5,696 Build 12: aarch64/2020/jun/20 pass: 5,695; fail: 1 Build 13: aarch64/2020/jun/23 pass: 5,695; fail: 1 Build 14: aarch64/2020/jun/27 pass: 5,696 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/08 pass: 8,649; fail: 504; error: 18 Build 1: aarch64/2019/aug/10 pass: 8,647; fail: 507; error: 17 Build 2: aarch64/2019/nov/12 pass: 8,650; fail: 513; error: 16 Build 3: aarch64/2019/nov/14 pass: 8,651; fail: 511; error: 17 Build 4: aarch64/2019/nov/16 pass: 8,663; fail: 500; error: 17 Build 5: aarch64/2019/dec/03 pass: 8,671; fail: 493; error: 18 Build 6: aarch64/2019/dec/14 pass: 8,653; fail: 516; error: 14 Build 7: aarch64/2020/jan/16 pass: 8,661; fail: 501; error: 21 Build 8: aarch64/2020/may/28 pass: 8,673; fail: 504; error: 17 Build 9: aarch64/2020/jun/02 pass: 8,686; fail: 509; error: 17 Build 10: aarch64/2020/jun/09 pass: 8,698; fail: 505; error: 16 Build 11: aarch64/2020/jun/18 pass: 8,712; fail: 495; error: 15 Build 12: aarch64/2020/jun/20 pass: 8,701; fail: 506; error: 16 Build 13: aarch64/2020/jun/23 pass: 8,691; fail: 517; error: 16 Build 14: aarch64/2020/jun/27 pass: 8,694; fail: 516; error: 16 6 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/08 pass: 3,964 Build 1: aarch64/2019/aug/10 pass: 3,964 Build 2: aarch64/2019/nov/12 pass: 3,964 Build 3: aarch64/2019/nov/14 pass: 3,964 Build 4: aarch64/2019/nov/16 pass: 3,964 Build 5: aarch64/2019/dec/03 pass: 3,964 Build 6: aarch64/2019/dec/14 pass: 3,964 Build 7: aarch64/2020/jan/16 pass: 3,964 Build 8: aarch64/2020/may/28 pass: 3,964 Build 9: aarch64/2020/jun/02 pass: 3,964 Build 10: aarch64/2020/jun/09 pass: 3,965 Build 11: aarch64/2020/jun/18 pass: 3,965 Build 12: aarch64/2020/jun/20 pass: 3,965 Build 13: aarch64/2020/jun/23 pass: 3,965 Build 14: aarch64/2020/jun/27 pass: 3,965 Previous results can be found here: http://openjdk.linaro.org/jdk13/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.54x Relative performance: Server critical-jOPS (nc): 8.55x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk13/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: 201.64 Server 201.64 / Server 2014-04-01 (71.00): 2.84x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk13/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-08-07 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/218/results/ 2019-08-09 pass rate: 10487/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/220/results/ 2019-08-11 pass rate: 10487/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/222/results/ 2019-11-12 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/316/results/ 2019-11-15 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/318/results/ 2019-11-17 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/320/results/ 2019-12-04 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/337/results/ 2019-12-15 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/348/results/ 2020-05-30 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2020/149/results/ 2020-06-04 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2020/154/results/ 2020-06-10 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2020/161/results/ 2020-06-20 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2020/170/results/ 2020-06-21 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2020/172/results/ 2020-06-25 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2020/175/results/ 2020-06-28 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2020/179/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/

1 0

[15] RFR: 8248048: ZGC: AArch64: SIGILL in load barrier register spilling
by Stefan Karlsson 26 Jun '20

26 Jun '20

Hi all, Please review this patch to fix a ZGC load barrier register spilling bug. https://cr.openjdk.java.net/~stefank/8248048/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8248048 The JVM crashed with an ILL_ILLOPC when executing this instruction in our load barrier stub: ldp q31, q31, [sp, #224] The entire load barrier stub: 0x0000ffff998ab964: stp x10, x13, [sp, #-32]! 0x0000ffff998ab968: stp x14, x17, [sp, #16] 0x0000ffff998ab96c: stp q1, q2, [sp, #-256]! 0x0000ffff998ab970: stp q3, q19, [sp, #32] 0x0000ffff998ab974: stp q20, q21, [sp, #64] 0x0000ffff998ab978: stp q22, q23, [sp, #96] 0x0000ffff998ab97c: stp q24, q25, [sp, #128] 0x0000ffff998ab980: stp q26, q28, [sp, #160] 0x0000ffff998ab984: stp q29, q30, [sp, #192] 0x0000ffff998ab988: stp q31, q31, [sp, #224] 0x0000ffff998ab98c: sub x1, x10, #0x0 0x0000ffff998ab990: mov x0, x11 0x0000ffff998ab994: mov x8, #0xfc28 // #64552 0x0000ffff998ab998: movk x8, #0xaf11, lsl #16 0x0000ffff998ab99c: movk x8, #0xffff, lsl #32 0x0000ffff998ab9a0: blr x8 ; branch into the JVM 0x0000ffff998ab9a4: mov x11, x0 0x0000ffff998ab9a8: ldp q3, q19, [sp, #32] 0x0000ffff998ab9ac: ldp q20, q21, [sp, #64] 0x0000ffff998ab9b0: ldp q22, q23, [sp, #96] 0x0000ffff998ab9b4: ldp q24, q25, [sp, #128] 0x0000ffff998ab9b8: ldp q26, q28, [sp, #160] 0x0000ffff998ab9bc: ldp q29, q30, [sp, #192] => 0x0000ffff998ab9c0: ldp q31, q31, [sp, #224] 0x0000ffff998ab9c4: ldp q1, q2, [sp], #256 0x0000ffff998ab9c8: ldp x14, x17, [sp, #16] 0x0000ffff998ab9cc: ldp x10, x13, [sp], #32 0x0000ffff998ab9d0: b 0xffff998aa718 It seems to be illegal to use the same register twice when loading into a pair of registers. I verified that that was the problem, and not the usage of zr (see below) that caused some weird encoding, by changing the code to always generate stp/ldp with the same register: => 0x0000ffff757d22fc: ldp q20, q20, [sp, #32] ; Crash here as well 0x0000ffff757d2300: ldp q21, q21, [sp, #48] 0x0000ffff757d2304: ldp q22, q22, [sp, #64] The code that generates this instruction is MacroAssembler::push_fp, which spills the necessary registers in pairs with stp/ldp calls. If the number of registers to spill is odd it needs to deal with one of the registers separately. This is done by adding a dummy register here: 2136 regs[count++] = zr->encoding_nocheck(); 2137 count &= ~1; // Only push an even number of regs This scheme seems to work for the normal registers (MacroAssembler::push), but the usage of zr seems dubious when we're dealing with the fp/simd version of stp/ldp. My proposed patch replaces the stp/ldp for the odd numbered register with the single-register versions: str/ldr. I make sure to keep the stack 16 bytes aligned by still bumping 16 bytes, but skipping the store/load to the second 8 bytes half. Note that right now MacroAssembler::push_fp is only used by ZGC. This fixes the crash. I've run this code through jtreg groups :tier1, tier2, tier3, and an Oracle-internal stress suite without any new problems. The smallest reproducer I have is: make -C ../build/fastdebug test TEST=test/jdk/java/util/concurrent/ JTREG="JAVA_OPTIONS=-XX:+UseZGC" Does this look OK? Thanks, StefanK

3 4

AARCH64 optimization: using TBZ instruction for bit check
by Boris Ulasevich 26 Jun '20

26 Jun '20

Hi all, Please review the new AARCH64 instruction selection rules. The change applies TBZ instruction for bit checks: "if ((var&16) == 16)". This makes 17% performance improvement on the benchmark and 5% on a real application. http://bugs.openjdk.java.net/browse/JDK-8247408 http://cr.openjdk.java.net/~bulasevich/8247408/webrev.00 - from the full change I excluded far branch test is because it works a long time, and I'm not sure C2 will not change its behaviour: http://cr.openjdk.java.net/~bulasevich/8247408/webrev.00.plus The change was tested on jtreg in fastdebug mode: no regressions. thanks, Boris ======================================================================================== Benchmark Mode Cnt Score Error Units Score Error TBZBenchmark.cmpAndBranch2Tbz thrpt 25 1329060.879 ± 42.780 ops/s 1504990.708 ± 158.096 TBZBenchmark.cmpAndBranch2Tbz:CPI thrpt 5 0.325 ± 0.001 #/op 0.410 ± 0.001 TBZBenchmark.cmpAndBranch2Tbz:L1-dcache-load-misses thrpt 5 0.019 ± 0.031 #/op 0.018 ± 0.025 TBZBenchmark.cmpAndBranch2Tbz:L1-dcache-loads thrpt 5 16.811 ± 0.791 #/op 16.809 ± 0.914 TBZBenchmark.cmpAndBranch2Tbz:L1-dcache-store-misses thrpt 5 0.016 ± 0.017 #/op 0.014 ± 0.022 TBZBenchmark.cmpAndBranch2Tbz:L1-dcache-stores thrpt 5 16.704 ± 0.634 #/op 16.771 ± 0.539 TBZBenchmark.cmpAndBranch2Tbz:L1-icache-load-misses thrpt 5 0.017 ± 0.027 #/op 0.016 ± 0.023 TBZBenchmark.cmpAndBranch2Tbz:L1-icache-loads thrpt 5 1811.848 ± 3.552 #/op 1148.737 ± 2.993 TBZBenchmark.cmpAndBranch2Tbz:branch-misses thrpt 5 1.013 ± 0.009 #/op 1.011 ± 0.018 TBZBenchmark.cmpAndBranch2Tbz:cycles thrpt 5 1882.193 ± 3.799 #/op 1662.994 ± 5.935 TBZBenchmark.cmpAndBranch2Tbz:dTLB-load-misses thrpt 5 0.004 ± 0.008 #/op 0.005 ± 0.016 TBZBenchmark.cmpAndBranch2Tbz:dTLB-loads thrpt 5 16.687 ± 0.732 #/op 16.669 ± 0.958 TBZBenchmark.cmpAndBranch2Tbz:iTLB-load-misses thrpt 5 0.003 ± 0.009 #/op 0.003 ± 0.008 TBZBenchmark.cmpAndBranch2Tbz:iTLB-loads thrpt 5 1586.390 ± 2.612 #/op 1353.981 ± 3.469 TBZBenchmark.cmpAndBranch2Tbz:instructions thrpt 5 5791.824 ± 15.362 #/op 4055.443 ± 17.785 TBZBenchmark.cmpAndBranch2Tbz:stalled-cycles-backend thrpt 5 5.279 ± 1.968 #/op 20.459 ± 5.258 TBZBenchmark.cmpAndBranch2Tbz:stalled-cycles-frontend thrpt 5 66.808 ± 0.700 #/op 12.738 ± 1.040 public class TBZBenchmark { @Benchmark public int cmpAndBranch2Tbz() { int count = 0; for (int value = 0; value < 1000; value++) { if ((value & 32) == 32) { count--; } else { count++; } } return count; } }

4 9

JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 13 on AArch64
by ci_notify＠linaro.org 25 Jun '20

25 Jun '20

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/jdk13/openjdk-jtreg-nightly-tests/summary/2020/17… ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/06 pass: 5,645; fail: 2 Build 1: aarch64/2019/aug/08 pass: 5,646; fail: 1 Build 2: aarch64/2019/aug/10 pass: 5,646; fail: 1 Build 3: aarch64/2019/nov/12 pass: 5,652 Build 4: aarch64/2019/nov/14 pass: 5,650; fail: 2 Build 5: aarch64/2019/nov/16 pass: 5,652 Build 6: aarch64/2019/dec/03 pass: 5,651; fail: 1 Build 7: aarch64/2019/dec/14 pass: 5,652 Build 8: aarch64/2020/jan/16 pass: 5,652 Build 9: aarch64/2020/may/28 pass: 5,669 Build 10: aarch64/2020/jun/02 pass: 5,677 Build 11: aarch64/2020/jun/09 pass: 5,691 Build 12: aarch64/2020/jun/18 pass: 5,696 Build 13: aarch64/2020/jun/20 pass: 5,695; fail: 1 Build 14: aarch64/2020/jun/23 pass: 5,695; fail: 1 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/06 pass: 8,616; fail: 528; error: 27 Build 1: aarch64/2019/aug/08 pass: 8,649; fail: 504; error: 18 Build 2: aarch64/2019/aug/10 pass: 8,647; fail: 507; error: 17 Build 3: aarch64/2019/nov/12 pass: 8,650; fail: 513; error: 16 Build 4: aarch64/2019/nov/14 pass: 8,651; fail: 511; error: 17 Build 5: aarch64/2019/nov/16 pass: 8,663; fail: 500; error: 17 Build 6: aarch64/2019/dec/03 pass: 8,671; fail: 493; error: 18 Build 7: aarch64/2019/dec/14 pass: 8,653; fail: 516; error: 14 Build 8: aarch64/2020/jan/16 pass: 8,661; fail: 501; error: 21 Build 9: aarch64/2020/may/28 pass: 8,673; fail: 504; error: 17 Build 10: aarch64/2020/jun/02 pass: 8,686; fail: 509; error: 17 Build 11: aarch64/2020/jun/09 pass: 8,698; fail: 505; error: 16 Build 12: aarch64/2020/jun/18 pass: 8,712; fail: 495; error: 15 Build 13: aarch64/2020/jun/20 pass: 8,701; fail: 506; error: 16 Build 14: aarch64/2020/jun/23 pass: 8,691; fail: 517; error: 16 4 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/06 pass: 3,964 Build 1: aarch64/2019/aug/08 pass: 3,964 Build 2: aarch64/2019/aug/10 pass: 3,964 Build 3: aarch64/2019/nov/12 pass: 3,964 Build 4: aarch64/2019/nov/14 pass: 3,964 Build 5: aarch64/2019/nov/16 pass: 3,964 Build 6: aarch64/2019/dec/03 pass: 3,964 Build 7: aarch64/2019/dec/14 pass: 3,964 Build 8: aarch64/2020/jan/16 pass: 3,964 Build 9: aarch64/2020/may/28 pass: 3,964 Build 10: aarch64/2020/jun/02 pass: 3,964 Build 11: aarch64/2020/jun/09 pass: 3,965 Build 12: aarch64/2020/jun/18 pass: 3,965 Build 13: aarch64/2020/jun/20 pass: 3,965 Build 14: aarch64/2020/jun/23 pass: 3,965 Previous results can be found here: http://openjdk.linaro.org/jdk13/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.54x Relative performance: Server critical-jOPS (nc): 8.55x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk13/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: 207.57 Server 207.57 / Server 2014-04-01 (71.00): 2.92x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk13/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-08-04 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/215/results/ 2019-08-07 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/218/results/ 2019-08-09 pass rate: 10487/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/220/results/ 2019-08-11 pass rate: 10487/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/222/results/ 2019-11-12 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/316/results/ 2019-11-15 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/318/results/ 2019-11-17 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/320/results/ 2019-12-04 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/337/results/ 2019-12-15 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/348/results/ 2020-05-30 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2020/149/results/ 2020-06-04 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2020/154/results/ 2020-06-10 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2020/161/results/ 2020-06-20 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2020/170/results/ 2020-06-21 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2020/172/results/ 2020-06-25 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2020/175/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/

1 0

JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 14 on AArch64
by ci_notify＠linaro.org 25 Jun '20

25 Jun '20

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/jdk14/openjdk-jtreg-nightly-tests/summary/2020/17… ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2020/jan/23 pass: 5,773; fail: 45 Build 1: aarch64/2020/jan/30 pass: 5,773; fail: 45 Build 2: aarch64/2020/feb/06 pass: 5,773; fail: 46 Build 3: aarch64/2020/feb/09 pass: 5,775; fail: 44 Build 4: aarch64/2020/apr/07 pass: 5,781; fail: 45 Build 5: aarch64/2020/may/05 pass: 5,762; fail: 45 Build 6: aarch64/2020/may/07 pass: 5,763; fail: 44 Build 7: aarch64/2020/may/12 pass: 5,761; fail: 46 Build 8: aarch64/2020/may/15 pass: 5,784; fail: 46 Build 9: aarch64/2020/may/28 pass: 5,785; fail: 45 Build 10: aarch64/2020/jun/01 pass: 5,784; fail: 47 Build 11: aarch64/2020/jun/04 pass: 5,787; fail: 45 Build 12: aarch64/2020/jun/13 pass: 5,786; fail: 46 Build 13: aarch64/2020/jun/23 pass: 5,786; fail: 46 2 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2020/jan/23 pass: 8,831; fail: 524; error: 18 Build 1: aarch64/2020/jan/30 pass: 8,839; fail: 518; error: 17 Build 2: aarch64/2020/feb/06 pass: 8,838; fail: 517; error: 18 Build 3: aarch64/2020/feb/09 pass: 8,832; fail: 523; error: 18 Build 4: aarch64/2020/apr/07 pass: 8,844; fail: 505; error: 20 Build 5: aarch64/2020/may/05 pass: 8,839; fail: 515; error: 18 Build 6: aarch64/2020/may/07 pass: 8,835; fail: 517; error: 20 Build 7: aarch64/2020/may/12 pass: 8,836; fail: 517; error: 19 Build 8: aarch64/2020/may/15 pass: 8,845; fail: 509; error: 18 Build 9: aarch64/2020/may/28 pass: 8,838; fail: 516; error: 18 Build 10: aarch64/2020/jun/01 pass: 8,847; fail: 509; error: 16 Build 11: aarch64/2020/jun/04 pass: 8,838; fail: 517; error: 17 Build 12: aarch64/2020/jun/13 pass: 8,846; fail: 510; error: 17 Build 13: aarch64/2020/jun/23 pass: 8,846; fail: 508; error: 19 3 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2020/jan/23 pass: 4,031 Build 1: aarch64/2020/jan/30 pass: 4,031 Build 2: aarch64/2020/feb/03 pass: 4,031 Build 3: aarch64/2020/feb/06 pass: 4,031 Build 4: aarch64/2020/feb/09 pass: 4,031 Build 5: aarch64/2020/apr/07 pass: 4,031 Build 6: aarch64/2020/may/05 pass: 4,031 Build 7: aarch64/2020/may/07 pass: 4,031 Build 8: aarch64/2020/may/12 pass: 4,031 Build 9: aarch64/2020/may/15 pass: 4,031 Build 10: aarch64/2020/may/28 pass: 4,031 Build 11: aarch64/2020/jun/01 pass: 4,031 Build 12: aarch64/2020/jun/04 pass: 4,031 Build 13: aarch64/2020/jun/13 pass: 4,031 Build 14: aarch64/2020/jun/23 pass: 4,031 Previous results can be found here: http://openjdk.linaro.org/jdk14/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): 9.48x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk14/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: 213.86 Server 213.86 / Server 2014-04-01 (71.00): 3.01x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk14/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2020-01-24 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/023/results/ 2020-02-01 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/030/results/ 2020-02-08 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/037/results/ 2020-02-10 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/040/results/ 2020-04-08 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/098/results/ 2020-05-06 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/126/results/ 2020-05-09 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/128/results/ 2020-05-14 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/133/results/ 2020-05-17 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/136/results/ 2020-05-30 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/149/results/ 2020-06-02 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/153/results/ 2020-06-07 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/156/results/ 2020-06-14 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/165/results/ 2020-06-25 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/175/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/

1 0