April 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(M): 8243392: Remodel CDS/Metaspace storage reservation
by Thomas Stüfe 22 May '20

22 May '20

Hi all, Could I have reviews for the following proposal of reworking cds/class space reservation? Bug: https://bugs.openjdk.java.net/browse/JDK-8243392 Webrev: http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webre… (Many thanks to Ioi Lam for so patiently explaining CDS internals to me, and to Andrew Haley and Nick Gasson for help with aarch64!) Reservation of the compressed class space is needlessly complicated and has some minor issues. It can be simplified and made clearer. The complexity stems from the fact that this area lives at the intersection of two to three sub systems, depending on how one counts. Metaspace, CDS, and the platform which may or may not its own view of how to reserve class space. And this code has been growing organically over time. One small example: ReservedSpace Metaspace::reserve_preferred_space(size_t size, size_t alignment, bool large_pages, char *requested_addr, bool use_requested_addr) which I spent hours decoding, resulting in a very confused mail to hs-runtime and aarch64-port-dev [2]. This patch attempts to simplify cds and metaspace setup a bit; to comment implicit knowledge which is not immediately clear; to cleanly abstract platform concerns like optimized class space placement; and to disentangle cds from metaspace to solve issues which may bite us later with Elastic Metaspace [4]. --- The main change is the reworked reservation mechanism. This is based on Ioi's proposal [5]. When reserving class space, three things must happen: 1) reservation of the space obviously. If cds is active that space must be in the vicinity of cds archives to be covered by compressed class pointer encoding. 2) setting up the internal Metaspace structures atop of that space 3) setting up compressed class pointer encoding. In its current form, Metaspace may or may not do some or all of that in one function (Metaspace::allocate_metaspace_compressed_klass_ptrs(ReservedSpace metaspace_rs, char* requested_addr, address cds_base);) - if cds is active, it will reserve the space for Metaspace and hand it in, otherwise it will create it itself. When discussing this in [2], Ioi proposed to move the reservation of the class space completely out of Metaspace and make it a responsibility of the caller always. This would reduce some complexity, and this patch follows the proposal. I removed Metaspace::allocate_metaspace_compressed_klass_ptrs(ReservedSpace metaspace_rs, char* requested_addr, address cds_base); and all its sub functions. (1) now has to always be done outside - a ReservedSpace for class space has to be provided by the caller. However, Metaspace now offers a utility function for reserving space at a "nice" location, and explicitly doing nothing else: ReservedSpace Metaspace::reserve_address_space_for_compressed_classes(size_t size); this function can be redefined on a platform level for platform optimized reservation, see below for details. (2) is taken care of by a new function, Metaspace::initialize_class_space(ReservedSpace rs) (3) is taken care of a new function CompressedKlassPointers::initialize(), see below for details. So, class space now is set up three explicit steps: - First, reserve a suitable space by however means you want. For convenience you may use Metaspace::reserve_address_space_for_compressed_classes(), or you may roll your own reservation. - Next, tell Metaspace to use that range as backing storage for class space: Metaspace::initialize_class_space(ReservedSpace rs) - Finally, set up encoding. Encoding is independent from the concept of a ReservedSpace, it just gets an address range, see below for details. Separating these steps and moving them out of the responsibility of Metaspace makes this whole thing more flexible; it also removes unnecessary knowledge (e.g. Metaspace does not need to know anything about either ccp encoding or cds). --- How it comes together: If CDS is off, we just reserve a space using Metaspace::reserve_address_space_for_compressed_classes(), initialize it with Metaspace::initialize_class_space(ReservedSpace rs), then set up compressed class pointer encoding covering the range of this class space. If CDS is on (dump time), we reserve large 4G space, either at SharedBaseAddress or using Metaspace::reserve_address_space_for_compressed_classes(); we then split that into 3G archive space and 1G class space; we set up that space with Metaspace as class space; then we set up compressed class pointer encoding covering both archive space and cds. If CDS is on (run time), we reserve a large space, split it into archive space (large enough to hold both archives) and class space, then basically proceed as above. Note that this is almost exactly how things worked before (modulo some minor fixes, e.g. alignment issues), only the code is reformed and made more explicit. --- I moved compressed class pointer setup over to CompressedKlassPointers and changed the interface: -void Metaspace::set_narrow_klass_base_and_shift(ReservedSpace metaspace_rs, address cds_base) +void CompressedKlassPointers::initialize(address addr, size_t len); Instead of feeding it a single ReservedSpace, which is supposed to represent class space, and an optional alternate base if cds is on, now we give it just an numeric address range. That range marks the limits to where Klass structures are to be expected, and is the implicit promise that outside that range no Klass structures will exist, so encoding has to cover only this range. This range may contain just the class space; or class space+cds; or whatever allocation scheme we come up with in the future. Encoding does not really care how the memory is organized as long as the input range covers all possible Klass locations. That way we remove knowledge about class space/cds from compressed class pointer encoding. Moving it away from metaspace.cpp into the CompressedKlassPointers class also mirrors CompressedOops::initialize(). --- I renamed _narrow_klass_range to just _range, because strictly speaking this is the range un-narrow Klass pointers can have. As for the implementation of CompressedKlassPointers::initialize(address addr, size_t len), I mimicked very closely what happened before, so there should be almost no differences. Since "almost no differences" sounds scary :) here are the differences: - When CDS is active (dump or run time) we now always, unconditionally, set the encoding range to 4G. This fixes a theoretical bug discussed on aarch64-port-dev [1]. - When CDS is not active, we set the encoding range to the minimum required length. Before, it was left at its default value of 4G. Both differences only affect aarch64, since they are currently the only one using the range field in CompressedKlassPointers. I wanted to add an assert somewhere to test encoding of the very last address of the CompressedKlassPointers range, again to prevent errors like [3]. But I did not come up with a good place for this assert which would cover also the encoding done by C1/C2. For the same reason I thought about introducing a mode where Klass structures would be allocated in reverse order, starting at the end of the ccs, but again left it out as too big a change. --- OS abstraction: platforms may have restrictions of what constitutes a valid compressed class pointer encoding base. Or if not, they may have at least preferences. There was logic like this in metaspace.cpp, which I removed and cleanly factored out into platform dependent files, giving each platform the option to add special logic. These are two new methods: - bool CompressedKlassPointers::is_valid_base(address p) to let the platform tell you whether it considers p to be a valid encoding base. The only platform having these restrictions currently is aarch64. - ReservedSpace Metaspace::reserve_address_space_for_compressed_classes(size_t size); this hands over the process of allocating a range suitable for compressed class pointer encoding to the platform. Most platforms will allocate just anywhere, but some platforms may have a better strategy (e.g. trying low memory first, trying only correctly aligned addresses and so on). Beforehand, this coding existed in a similar form in metaspace.cpp for aarch64 and AIX. For now, I left the AIX part out - it seems only half done, and I want to check further if we even need it, if yes why not on Linux ppc, and C1 does not seem to support anything other than base+offset with shift either, but I may be mistaken. These two methods should give the platform enough control to implement their own scheme for optimized class space placement without bothering any shared code about it. Note about the form, I introduced two new platform dependent files, "metaspace_<cpu>.cpp" and "compressedOops_<cpu>.cpp". I am not happy about this but this seems to be what we generally do in hotspot, right? --- Metaspace reserve alignment vs cds alignment CDS was using Metaspace reserve alignment for CDS internal purposes. I guess this was just a copy paste issue. It never caused problems since Metaspace reserve alignment == page size, but that is not true anymore in the upcoming Elastic Metaspace where reserve alignment will be larger. This causes a number of issues. I separated those two cleanly. CDS now uses os::vm_allocation_granularity. Metaspace::reserve_alignment is only used in those two places where it is needed, when CDS creates the address space for class space on behalf of the Metaspace. --- Windows special handling in CDS To simplify coding I removed the windows specific handling which left out reservation of the archive. This was needed because windows cannot mmap files into reserved regions. But fallback code exists in filemap.cpp for this case which just reads in the region instead of mapping it. Should that turn out to be a performance problem, I will reinstate the feature. But a simpler way would be reserve the archive and later just before mmapping the archive file to release the archive space. That would not only be simpler but give us the best guarantee that that address space is actually available. But I'd be happy to leave that part out completely if we do not see any performance problems on windows x64. --- NMT cannot deal with spaces which are split. This problem manifests in that bookkeeping for class space is done under "Shared Classes", not "Classes" as it should. This problem exists today too at dump time and randomly at run time. But since I simplified the reservation, this problem now shows up always, whether or not we map at the SharedBaseAddress. While I could work around this problem, I'd prefer this problem to be solved at the core, and NMT to have an option to recognize reservation splits. So I'd rather not put a workaround for this into the patch but leave it for fixing as a separate issue. I opened this issue to track it [6]. --- Jtreg tests: I expanded the CompressedOops/CompressedClassPointers.java. I also extended them to Windows. The tests now optionally omit strict class space placement tests, since these tests heavily depend on ASLR and were the reason they were excluded on Windows. However I think even without checking for class space placement they make sense, just to see that the VM comes up and lives with the many different settings we can run in. --- Tests: - I ran the patch through Oracles submit repo - I ran tests manually for aarch64, zero, linux 32bit and windows x64 - The whole battery of nightly tests at SAP, including ppc, ppcle and aarch64, unfortunately excluding windows because of unrelated errors. Windows x64 tests will be redone tonight. Thank you, Thomas [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008804.… [2] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008757.… [3] https://bugs.openjdk.java.net/browse/JDK-8193266 [4] https://bugs.openjdk.java.net/browse/JDK-8221173 [5] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008765.… [6] https://bugs.openjdk.java.net/browse/JDK-8243535

5 39

FW: [Mach5] mach5-one-phh-JDK-8151779-20200427-2151-10554367: FAILED
by Liu, Xin 01 May '20

01 May '20

Hello, I recently received some build failures from submit repo. May I know more details ? eg. linux-x64-linux-x64-build-5, linux-x64-debug-linux-x64-build-6 I have successfully built it on the latest linux on ubuntu 18.04 with gcc 7.5. My nightly buildbot started failing recently on aarch64. One issue is the error message of [cds] prevents configure from bootjdk determining. https://hg.openjdk.java.net/jdk/jdk/file/1b8f9e72b22b/make/autoconf/boot-jd… ./bin/java --version [0.006s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096 openjdk 14.0.1 2020-04-14 OpenJDK Runtime Environment AdoptOpenJDK (build 14.0.1+7) OpenJDK 64-Bit Server VM AdoptOpenJDK (build 14.0.1+7, mixed mode) Are you aware of this issue? I can’t see [cds] line on my linux/x86_64 host. Maybe it’s aarch64-only. CC aarch-port-dev. Thanks, --lx From: <do-not-reply(a)oracle.com> on behalf of "do-not-reply(a)oracle.com" <do-not-reply(a)oracle.com> Reply-To: "mach5_admin_ww_grp(a)oracle.com" <mach5_admin_ww_grp(a)oracle.com> Date: Monday, April 27, 2020 at 3:46 PM To: "Hohensee, Paul" <hohensee(a)amazon.com> Subject: [EXTERNAL] [Mach5] mach5-one-phh-JDK-8151779-20200427-2151-10554367: FAILED Job: mach5-one-phh-JDK-8151779-20200427-2151-10554367 BuildId: 2020-04-27-2150109.hohensee.source No failed tests Tasks Summary * NOTHING_TO_RUN: 0 * UNABLE_TO_RUN: 24 * KILLED: 0 * NA: 0 * HARNESS_ERROR: 0 * FAILED: 0 * EXECUTED_WITH_FAILURE: 9 * PASSED: 51 Build 2 Unable to run * linux-aarch64-install-linux-aarch64-build-signing-20 Dependency task failed: mach5...-10554367-linux-aarch64-linux-aarch64-build-1 * linux-x64-install-linux-x64-build-signing-21 Dependency task failed: mach5...427-2151-10554367-linux-x64-linux-x64-build-5 9 Executed with failure * linux-aarch64-linux-aarch64-build-1 error while building, return value: 2 * linux-aarch64-debug-linux-aarch64-build-2 error while building, return value: 2 * linux-aarch64-open-linux-aarch64-build-3 error while building, return value: 2 * linux-aarch64-open-debug-linux-aarch64-build-4 error while building, return value: 2 * linux-x64-linux-x64-build-5 error while building, return value: 2 * linux-x64-debug-linux-x64-build-6 error while building, return value: 2 * linux-x64-debug-nopch-linux-x64-build-9 error while building, return value: 2 * linux-x64-open-linux-x64-build-7 error while building, return value: 2 * linux-x64-open-debug-linux-x64-build-8 error while building, return value: 2 Test 22 Unable to run * tier1-product-open_test_hotspot_jtreg_tier1_common-linux-x64-24 Dependency task failed: mach5...427-2151-10554367-linux-x64-linux-x64-build-5 * tier1-debug-open_test_hotspot_jtreg_tier1_common-linux-x64-debug-30 Dependency task failed: mach5...51-10554367-linux-x64-debug-linux-x64-build-6 * tier1-debug-open_test_hotspot_jtreg_tier1_compiler_1-linux-x64-debug-33 Dependency task failed: mach5...51-10554367-linux-x64-debug-linux-x64-build-6 * tier1-debug-open_test_hotspot_jtreg_tier1_compiler_2-linux-x64-debug-36 Dependency task failed: mach5...51-10554367-linux-x64-debug-linux-x64-build-6 * tier1-debug-open_test_hotspot_jtreg_tier1_compiler_3-linux-x64-debug-39 Dependency task failed: mach5...51-10554367-linux-x64-debug-linux-x64-build-6 * tier1-debug-open_test_hotspot_jtreg_tier1_compiler_graal-linux-x64-debug-45 Dependency task failed: mach5...51-10554367-linux-x64-debug-linux-x64-build-6 * tier1-debug-open_test_hotspot_jtreg_tier1_compiler_not_xcomp-linux-x64-debug-42 Dependency task failed: mach5...51-10554367-linux-x64-debug-linux-x64-build-6 * tier1-debug-open_test_hotspot_jtreg_tier1_gc_1-linux-x64-debug-48 Dependency task failed: mach5...51-10554367-linux-x64-debug-linux-x64-build-6 * tier1-debug-open_test_hotspot_jtreg_tier1_gc_2-linux-x64-debug-51 Dependency task failed: mach5...51-10554367-linux-x64-debug-linux-x64-build-6 * tier1-product-open_test_hotspot_jtreg_tier1_gc_gcbasher-linux-x64-27 Dependency task failed: mach5...427-2151-10554367-linux-x64-linux-x64-build-5 * See all 22...

6 9

Re: [aarch64-port-dev ] RFR(XS): 8230552: Provide information when hitting a HaltNode for architectures other than x86
by Liu, Xin 30 Apr '20

30 Apr '20

On 4/29/20, 11:06 PM, "Pengfei Li" <Pengfei.Li(a)arm.com> wrote: Hi Xin, > I tested on aarch64. It generates the same crash report as x86_64 when it > does hit HaltNode. Halt reason is displayed. I paste report on the JBS. > I ran hotspot:tier1 on aarch64 fastdebug build. It passed except for 3 > relevant failures[1]. (NOT a reviewer) The original instruction used should be dcps1 instead of dpcs1 - there's a misspelling in AArch64 assembler. Could you add a trivial fix to change dpcs1/2/3 to dcps1/2/3? Oh, I don't know that. I did search dpcs and found nothing. I've filed a new issue about the typo thing: JDK-8244170. Let's resolve it in separated issue. BTW, how did you test to hit the HaltNode? -- Thanks, Pengfei I followed Christian and Volkers' recipe on JDK-8230552. Both of them can generate HaltNode. Volker's approach is very interesting. You have to give program a couple of "-XX:SuppressErrorAt=" to increase tolerance. Thanks, --lx

2 1

Re: [aarch64-port-dev ] RFR(XS): Provide information when hitting a HaltNode for architectures other than x86
by Pengfei Li 30 Apr '20

30 Apr '20

Hi Xin, > I tested on aarch64. It generates the same crash report as x86_64 when it > does hit HaltNode. Halt reason is displayed. I paste report on the JBS. > I ran hotspot:tier1 on aarch64 fastdebug build. It passed except for 3 > relevant failures[1]. (NOT a reviewer) The original instruction used should be dcps1 instead of dpcs1 - there's a misspelling in AArch64 assembler. Could you add a trivial fix to change dpcs1/2/3 to dcps1/2/3? BTW, how did you test to hit the HaltNode? -- Thanks, Pengfei

1 0

[15] RFR 8241793: Shenandoah: Enable concurrent class unloading for aarch64
by Zhengyu Gu 29 Apr '20

29 Apr '20

Concurrent class unloading support for aarch64 [1] has been pushed, let's enable it for Shenandoah GC. Bug: https://bugs.openjdk.java.net/browse/JDK-8241793 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8241793/webrev.00/ Test: hotspot_gc_shenandoah tier1 with Shenandoah GC Thanks, -Zhengyu [1] https://bugs.openjdk.java.net/browse/JDK-8216557

1 0

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): 8243155: AArch64: Add support for SqrtVF
by Yang Zhang 28 Apr '20

28 Apr '20

Hi, Could you please help to review this patch? JBS: https://bugs.openjdk.java.net/browse/JDK-8243155 Webrev: http://cr.openjdk.java.net/~yzhang/8243155/webrev.00/ In Java, Math.sqrt() supports double data only. To support Math.sqrt() for float, the following conversion must be done. float a, b; a = (float)Math.sqrt((double)b) Both AArch64 and x86 support such single-precision sqrt by hardware instructions. AArch64 FSQRT instruction matches Java (float)Math. sqrt((double)b) exactly. And X86 has supported vectorization of Math.sqrt() on floats in [1]. In this patch, vectorized sqrt for float (SqrtVF) is supported in AArch64 backend. Jtreg test cases for SqrtVF and SqrtVD are also added. Special cases such as min/max, +/-Inf, +0.0/-0.0 and NaN are covered. Testing: Full jtreg Newly added sqrt jtreg tests Panama/Vector API tests which cover vector sqrt Test case for sqrtvf: public static void sqrtvf(float[] a, float[] b, float[] c) { float tmp; for (int i = 0; i < a.length; i++) { tmp = (float)(a[i] + b[i]); c[i] = (float)Math.sqrt((double)tmp); } } With this patch, the following code snippet is generated. 0x0000ffffacaf872c: ldr q17, [x18, #16] 0x0000ffffacaf8730: ldr q16, [x16, #16] 0x0000ffffacaf8734: fadd v16.4s, v16.4s, v17.4s 0x0000ffffacaf8738: fsqrt v16.4s, v16.4s 0x0000ffffacaf8740: str q16, [x14, #16] Performance: JMH test is attached in JBS. Before: Benchmark (size) Mode Cnt Score Error Units TestVect.testVectSqrtVF 1024 avgt 5 4.372 ± 0.016 us/op After: Benchmark (size) Mode Cnt Score Error Units TestVect.testVectSqrtVF 1024 avgt 5 1.115 ± 0.013 us/op [1] https://bugs.openjdk.java.net/browse/JDK-8190800 Regards Yang

2 1

RFR(S): 8243240: AArch64: Add support for MulVB
by Yang Zhang 24 Apr '20

24 Apr '20

Hi, Could you please help to review this patch? JBS: https://bugs.openjdk.java.net/browse/JDK-8243240 Webrev: http://cr.openjdk.java.net/~yzhang/8243240/webrev.00/ In this patch, the missing MulVB support for AArch64 is added. Testing: tier1 Test case: public static void mulvb(byte[] a, byte[] b, byte[] c) { for (int i = 0; i < a.length; i++) { c[i] = (byte)(a[i] * b[i]); } } Assembly generated by C2: 0x0000ffffacafdbac: ldr q17, [x15, #16] 0x0000ffffacafdbb0: ldr q16, [x14, #16] 0x0000ffffacafdbb4: mul v16.16b, v16.16b, v17.16b 0x0000ffffacafdbbc: str q16, [x11, #16] Performance: JMH test case is attached in JBS. Before: Benchmark (size) Mode Cnt Score Error Units TestVect.testVectMulVB 1024 avgt 5 0.952 0.005 us/op After: Benchmark (size) Mode Cnt Score Error Units TestVect.testVectMulVB 1024 avgt 5 0.110 0.001 us/op Regards Yang

2 1

RFR(XS): 8242905: AArch64: Client build failed
by Yang Zhang 23 Apr '20

23 Apr '20

Hi, Could you please help to review this patch? JBS: https://bugs.openjdk.java.net/browse/JDK-8242905 Webrev: http://cr.openjdk.java.net/~yzhang/8242905/webrev.00/ This issue is introduced by [1]. In this commit, pop_CPU_state(restore _vectors) and leave() are included under COMPILER2_OR_JVMCI check in AArc64 restore_live_registers[2]. But restore_live_registers is used in generate_resolve_blob[3] which might be called from c1. In x86 restore_live_registers, pop_CPU_state() and pop(rbp) are always done [4]. To fix this issue, pop_CPU_state(restore_vectors) and leave() are also moved outside of COMPILER2_OR_JVMCI check in AArch64 restore_live_registers. Testing on AArch64 platform: tier1 test with server build server build with configuring --with-jvm-features=-compiler2 client build and ran HelloWorld [1] https://bugs.openjdk.java.net/browse/JDK-8241665 [2] https://hg.openjdk.java.net/jdk/jdk/rev/53568400fec3#l1.23 [3] http://hg.openjdk.java.net/jdk/jdk/file/55c4283a7606/src/hotspot/cpu/aarch6… [4] http://hg.openjdk.java.net/jdk/jdk/file/55c4283a7606/src/hotspot/cpu/x86/sh…

3 2