August 2020 - aarch64-port-dev

RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic
by Yangfei (Felix) 17 Sep '20

17 Sep '20

Hi, Bug: https://bugs.openjdk.java.net/browse/JDK-8252204 Webrev: http://cr.openjdk.java.net/~fyang/8252204/webrev.00/ This added an intrinsic for SHA3 using aarch64 v8.2 SHA3 Crypto Extensions. Reference implementation for core SHA-3 transform using ARMv8.2 Crypto Extensions: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/… Trivial adaptation in SHA3. implCompress is needed for the purpose of adding the intrinsic. For SHA3, we need to pass one extra parameter "digestLength" to the stub for the calculation of block size. "digestLength" is also used in for the EOR loop before keccak to differentiate different SHA3 variants. We added jtreg tests for SHA3 and used QEMU system emulator which supports SHA3 instructions to test the functionality. Patch passed jtreg tier1-3 tests with QEMU system emulator. Also verified with jtreg tier1-3 tests without SHA3 instructions on aarch64-linux-gnu and x86_64-linux-gnu, to make sure that there's no regression. We used one existing JMH test for performance test: test/micro/org/openjdk/bench/java/security/MessageDigests.java We measured the performance benefit with an aarch64 cycle-accurate simulator. Patch delivers 20% - 40% performance improvement depending on specific SHA3 digest length and size of the message. For now, this feature will not be enabled automatically for aarch64. We can auto-enable this when it is fully tested on real hardware. But for the above testing purposes, this is auto-enabled when the corresponding hardware feature is detected. Comments? Thanks, Felix

4 8

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

CFV: New aarch64-port Committer: Ludovic Henry
by Andrew Haley 10 Sep '20

10 Sep '20

I hereby nominate Ludovic Henry to aarch64-port Committer. Ludovic Henry is a member of the team at Microsoft working on the AArch64 port to Windows. They have already pushed some excellent patches to OpenJDK. Only current aarch64-port Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. Votes are due by 12:00 GMT August 18, 2020. For Lazy Consensus voting instructions, see [2]. Thank you! [1] http://openjdk.java.net/census#aarch64-port [2] http://openjdk.java.net/projects/#committer-vote -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

7 10

[16] RFR(S): 8251525: AARCH64: Faster Math.signum(fp)
by Dmitry Chuyko 06 Sep '20

06 Sep '20

Hello, Please review a faster version of Math.signum() for AArch64. Two new intrinsics (double and float) are introduced in general code, with appropriate new nodes. New JTreg test is added to cover the intrinsic case (enabled only for aarch64). AArch64 implementation uses FACGT (compare abslute fp values) and BSL (fp bit selection) to avoid branches and moves to non-fp registers and back. Performance results show ~30% better time in the benchmark with a black hole [1] on Cortex. E.g. on random numbers 4.8 ns/op --> 3.5 ns/op, overhead is 2.9 ns/op. rfe: https://bugs.openjdk.java.net/browse/JDK-8251525 webrev: http://cr.openjdk.java.net/~dchuyko/8251525/webrev.00/ testing: jck, jtreg including new dedicated test -Dmitry [1] https://cr.openjdk.java.net/~dchuyko/8249198/DoubleSignum.java

6 24

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

A binary download for aarch64.
by Terje Kvernes 01 Sep '20

01 Sep '20

Dear all, I am currently working on expanding EasyBuilds[1] support for ARM in the HPC space. One of the hurdles I have come across is that EasyBuild on both x86_64 and POWER install OpenJDK as a binary. On x86_64 this is done by fetching and installing https://download.java.net/java/GA/jdk11/9/GPL/openjdk-11.0.2_linux-x64_bin.… <https://download.java.net/java/GA/jdk11/9/GPL/openjdk-11.0.2_linux-x64_bin.…>, linked from https://jdk.java.net/archive/ <https://jdk.java.net/archive/>. Now, I have been unable to find a similar service for aarch64, and I was hoping I had simply missed something. Is there such a binary available for aarch64? [1] https://easybuild.readthedocs.io/en/latest/ -- Terje Kvernes

3 3

hg: aarch64-port/jdk-windows: If you insist
by aph＠redhat.com 31 Aug '20

31 Aug '20

Changeset: 40e31a529468 Author: aph Date: 2020-08-28 18:21 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk-windows/rev/40e31a529468 If you insist - DELETEME

3 3

Linaro OpenJDK AArch64 jdk/jdk build 4337 Failure
by ci_notify＠linaro.org 31 Aug '20

31 Aug '20

OpenJDK AArch64 jdk/jdk build status is Failure Build details - https://ci.linaro.org/jenkins/job/jdkX-ci-build/4337/ Changes - pconcannon: e10f558e1df506f1b7ef825cb0239074d69f2939 - test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/mapMultiOpTest.java - src/java.base/share/classes/java/util/stream/DoublePipeline.java - src/java.base/share/classes/java/util/stream/DoubleStream.java - src/java.base/share/classes/java/util/stream/IntPipeline.java - src/java.base/share/classes/java/util/stream/IntStream.java - src/java.base/share/classes/java/util/stream/LongPipeline.java - src/java.base/share/classes/java/util/stream/LongStream.java - src/java.base/share/classes/java/util/stream/ReferencePipeline.java - src/java.base/share/classes/java/util/stream/Stream.java - test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/FlatMapOpTest.java --"8238286: Add new flatMap stream operation that is more amenable to pushing Summary: This patch adds a new flatmap-like operation called mapMulti to the java.util.Stream class as well as the primitive variations of this operation i.e. mapMultiToInt, IntStream mapMulti, etc. Reviewed-by: psandoz, smarks " iklam: ee2c69f0637051d304c1d8c9428e4ff9f3a47b20 - src/hotspot/share/classfile/classLoadInfo.hpp - src/hotspot/share/aot/aotCodeHeap.cpp - src/hotspot/share/ci/ciField.cpp - src/hotspot/share/ci/ciReplay.cpp - src/hotspot/share/classfile/classFileParser.cpp - src/hotspot/share/classfile/classListParser.cpp - src/hotspot/share/classfile/classLoader.cpp - src/hotspot/share/classfile/classLoaderExt.cpp - src/hotspot/share/classfile/dictionary.cpp - src/hotspot/share/classfile/dictionary.hpp - src/hotspot/share/classfile/javaClasses.cpp - src/hotspot/share/classfile/javaClasses.hpp - src/hotspot/share/classfile/klassFactory.cpp - src/hotspot/share/classfile/systemDictionary.cpp - src/hotspot/share/classfile/systemDictionary.hpp - src/hotspot/share/classfile/systemDictionaryShared.hpp - src/hotspot/share/gc/g1/g1Arguments.cpp - src/hotspot/share/gc/g1/g1CollectedHeap.cpp - src/hotspot/share/gc/parallel/mutableNUMASpace.cpp - src/hotspot/share/gc/parallel/psParallelCompact.cpp - src/hotspot/share/gc/shared/gcVMOperations.cpp - src/hotspot/share/jfr/instrumentation/jfrEventClassTransformer.cpp - src/hotspot/share/jvmci/jvmciCompilerToVM.cpp - src/hotspot/share/jvmci/jvmciJavaClasses.cpp - src/hotspot/share/jvmci/jvmciRuntime.cpp - src/hotspot/share/memory/virtualspace.cpp - src/hotspot/share/oops/instanceKlass.cpp - src/hotspot/share/oops/klass.inline.hpp - src/hotspot/share/prims/jvm.cpp - src/hotspot/share/prims/jvmtiRedefineClasses.cpp - src/hotspot/share/prims/methodHandles.cpp - src/hotspot/share/prims/unsafe.cpp - src/hotspot/share/runtime/fieldDescriptor.inline.hpp - src/hotspot/share/runtime/signature.cpp - src/hotspot/share/runtime/signature.hpp --"8251560: Remove excessive header file inclusion from systemDictionary.hpp and others Reviewed-by: coleenp " Build output - Compiling 14 files for jdk.management.jfr Compiling 8 files for jdk.net Compiling 2 files for jdk.nio.mapmode Compiling 33 files for jdk.sctp Compiling 94 files for jdk.xml.dom Compiling 14 files for jdk.zipfs Compiling 15 files for java.prefs Compiling 197 files for java.naming Compiling 77 files for java.sql Compiling 15 files for jdk.attach Compiling 74 files for jdk.crypto.cryptoki Compiling 136 files for jdk.jdeps Compiling 40 files for jdk.jcmd Compiling 251 files for jdk.jdi Compiling 16 files for jdk.naming.dns Compiling 8 files for jdk.naming.rmi Compiling 2781 files for java.desktop Compiling 16 files for java.management.rmi Compiling 219 files for java.security.jgss Compiling 56 files for java.sql.rowset Compiling 83 files for jdk.jlink Compiling 31 files for jdk.management.agent Compiling 95 files for jdk.jshell Compiling 30 files for jdk.security.auth Compiling 16 files for jdk.security.jgss Compiling 1644 files for jdk.internal.vm.compiler Compiling 107 files for jdk.aot Compiling 70 files for COMPILE_CREATE_SYMBOLS Creating ct.sym classes Compiling 3 files for jdk.internal.vm.compiler.management Compiling 64 files for jdk.jconsole Compiling 8 files for jdk.unsupported.desktop Compiling 1 files for java.se Compiling 18 files for jdk.accessibility Updating support/src.zip Compiling 3 files for jdk.editpad Compiling 944 files for jdk.hotspot.agent Compiling 47 files for jdk.incubator.jpackage /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp: In member function 'virtual void ShenandoahArguments::initialize()': /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp:77:100: error: 'vm_exit_during_initialization' was not declared in this scope vm_exit_during_initialization("Shenandoah expects ConcGCThreads > 0, check -XX:ConcGCThreads=#"); ^ /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp:91:108: error: 'vm_exit_during_initialization' was not declared in this scope vm_exit_during_initialization("Shenandoah expects ParallelGCThreads > 0, check -XX:ParallelGCThreads=#"); ^ /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp:104:78: error: 'vm_exit_during_initialization' was not declared in this scope vm_exit_during_initialization("Shenandoah thread count ergonomic error"); ^ /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp:107:140: error: 'vm_exit_during_initialization' was not declared in this scope vm_exit_during_initialization("Shenandoah expects ConcGCThreads <= ParallelGCThreads, check -XX:ParallelGCThreads, -XX:ConcGCThreads"); ^ At global scope: cc1plus: error: unrecognized command line option '-Wno-shift-negative-value' [-Werror] cc1plus: error: unrecognized command line option '-Wno-cast-function-type' [-Werror] cc1plus: error: unrecognized command line option '-Wno-misleading-indentation' [-Werror] cc1plus: error: unrecognized command line option '-Wno-implicit-fallthrough' [-Werror] cc1plus: error: unrecognized command line option '-Wno-int-in-bool-context' [-Werror] cc1plus: all warnings being treated as errors lib/CompileJvm.gmk:141: recipe for target '/home/buildslave/workspace/jdkX-ci-build/build/hotspot/variant-server/libjvm/objs/shenandoahArguments.o' failed make[3]: *** [/home/buildslave/workspace/jdkX-ci-build/build/hotspot/variant-server/libjvm/objs/shenandoahArguments.o] Error 1 make[3]: *** Waiting for unfinished jobs.... make/Main.gmk:259: recipe for target 'hotspot-server-libs' failed make[2]: *** [hotspot-server-libs] Error 1 ERROR: Build failed for target 'images' in configuration '/home/buildslave/workspace/jdkX-ci-build/build' (exit code 2) === Output from failing command(s) repeated here === * For target hotspot_variant-server_libjvm_objs_shenandoahArguments.o: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp: In member function 'virtual void ShenandoahArguments::initialize()': /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp:77:100: error: 'vm_exit_during_initialization' was not declared in this scope vm_exit_during_initialization("Shenandoah expects ConcGCThreads > 0, check -XX:ConcGCThreads=#"); ^ /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp:91:108: error: 'vm_exit_during_initialization' was not declared in this scope vm_exit_during_initialization("Shenandoah expects ParallelGCThreads > 0, check -XX:ParallelGCThreads=#"); ^ /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp:104:78: error: 'vm_exit_during_initialization' was not declared in this scope vm_exit_during_initialization("Shenandoah thread count ergonomic error"); ^ /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp:107:140: error: 'vm_exit_during_initialization' was not declared in this scope vm_exit_during_initialization("Shenandoah expects ConcGCThreads <= ParallelGCThreads, check -XX:ParallelGCThreads, -XX:ConcGCThreads"); ^ At global scope: cc1plus: error: unrecognized command line option '-Wno-shift-negative-value' [-Werror] ... (rest of output omitted) * All command lines available in /home/buildslave/workspace/jdkX-ci-build/build/make-support/failure-logs. === End of repeated output === === Make failed targets repeated here === lib/CompileJvm.gmk:141: recipe for target '/home/buildslave/workspace/jdkX-ci-build/build/hotspot/variant-server/libjvm/objs/shenandoahArguments.o' failed make/Main.gmk:259: recipe for target 'hotspot-server-libs' failed === End of repeated output === Hint: Try searching the build log for the name of the first failed target. Hint: See doc/building.html#troubleshooting for assistance. /home/buildslave/workspace/jdkX-ci-build/jdkX/make/Init.gmk:310: recipe for target 'main' failed make[1]: *** [main] Error 1 /home/buildslave/workspace/jdkX-ci-build/jdkX/make/Init.gmk:186: recipe for target 'images' failed make: *** [images] Error 2

1 0

Re: [aarch64-port-dev ] [16] RFR(S): 8251525: AARCH64: Faster Math.signum(fp)
by Hohensee, Paul 30 Aug '20

30 Aug '20

One's perspective on the benchmark results depends on the expected frequency of the input types. If we don't expect frequent NaNs (I don’t, because they mean your algorithm is numerically unstable and you're wasting your time running it), or zeros (somewhat arguable, but note that most codes go to some lengths to eliminate zeros, e.g., using sparse arrays), then this patch seems to me to be a win. Thanks, Paul On 8/25/20, 9:57 AM, "hotspot-compiler-dev on behalf of Andrew Haley" <hotspot-compiler-dev-retn(a)openjdk.java.net on behalf of aph(a)redhat.com> wrote: On 24/08/2020 22:52, Dmitry Chuyko wrote: > > I added two more intrinsics -- for copySign, they are controlled by > UseCopySignIntrinsic flag. > > webrev: http://cr.openjdk.java.net/~dchuyko/8251525/webrev.03/ > > It also contains 'benchmarks' directory: > http://cr.openjdk.java.net/~dchuyko/8251525/webrev.03/benchmarks/ > > There are 8 benchmarks there: (double | float) x (blackhole | reduce) x > (current j.l.Math.signum | abs()>0 check). > > My results on Arm are in signum-facgt-copysign.ods. Main case is > 'random' which is actually a random from positive and negative numbers > between -0.5 and +0.5. > > Basically we have ~14% improvement in 'reduce' benchmark variant but > ~20% regression in 'blackhole' variant in case of only copySign() > intrinsified. > > Same picture if abs()>0 check is used in signum() (+-5%). This variant > is included as it shows very good results on x86. > > Intrinsic for signum() gives improvement of main case in both > 'blackhole' and 'reduce' variants of benchmark: 28% and 11%, which is a > noticeable difference. Ignoring Blackhole for the moment, this is what I'm seeing for the reduction/random case: Benchmark Mode Cnt Score Error Units ThunderX 2: -XX:-UseSignumIntrinsic -XX:-UseCopySignIntrinsic DoubleReduceBench.ofRandom avgt 3 2.456 ± 0.065 ns/op -XX:+UseSignumIntrinsic -XX:-UseCopySignIntrinsic DoubleReduceBench.ofRandom avgt 3 2.766 ± 0.107 ns/op -XX:-UseSignumIntrinsic -XX:+UseCopySignIntrinsic DoubleReduceBench.ofRandom avgt 3 2.537 ± 0.770 ns/op Neoverse N1 (Actually Amazon m6g.16xlarge): -XX:-UseSignumIntrinsic -XX:-UseCopySignIntrinsic DoubleReduceBench.ofRandom avgt 3 1.173 ± 0.001 ns/op -XX:+UseSignumIntrinsic -XX:-UseCopySignIntrinsic DoubleReduceBench.ofRandom avgt 3 1.043 ± 0.022 ns/op -XX:-UseSignumIntrinsic -XX:+UseCopySignIntrinsic DoubleReduceBench.ofRandom avgt 3 1.012 ± 0.001 ns/op By your own numbers, in the reduce benchmark the signum intrinsic is worse than default for all 0 and NaN, but about 12% better for random, >0, and <0. If you take the average of the sppedups and slowdowns it's actually worse than default. By my reckoning, if you take all possibilities (Nan, <0, >0, 0, Random) into account, the best-performing on the reduce test is actually Abs/Copysign, but there's very little in it. The only time that the signum intrinsic actually wins is when you're storing the result into memory *and* flushing the store buffer. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

2 1

RFR: Bulk integration shenandoah/jdk8 -> aarch64-port/jdk8u-shenandoah, 2020-08-26
by Aleksey Shipilev 28 Aug '20

28 Aug '20

Hi, I would like to integrate the usual round of sh/jdk8 backports to aarch64-port/jdk8u-shenandoah. Only hotspot repository is affected, and the merge is clean there. Since we need to coordinate the push with Andrew Hughes, I did not tag it yet. It would be something like "aarch64-shenandoah-jdk8u272-b03-shenandoah-merge-2020-08-26". 8u webrev: https://cr.openjdk.java.net/~shade/shenandoah/merges/aarch64-port-8u-202008… Testing: hotspot_gc_shenandoah; plus, this was tested with sh/jdk8 CIs -- Thanks, -Aleksey

3 4