May 2019 - aarch64-port-dev

RFR: 8218748: AARCH64: String::compareTo intrinsic documentation and maintenance improvement
by Dmitrij Pochepko 18 Nov '19

18 Nov '19

Hi all. Please review an enhancement change "8218748: AARCH64: String::compareTo intrinsic documentation and maintenance improvement". RFE: https://bugs.openjdk.java.net/browse/JDK-8218748 webrev: http://cr.openjdk.java.net/~dpochepk/8218748/webrev/ Changes: - Added documentation for compareTo implementation. - Removed duplicated code and using existing code instead. -- compare_string_16_bytes_same is used for tail handling in generate_compare_long_string_same_encoding . -- DIFF block code is reused for DIFF2 block in generate_compare_long_string_same_encoding. - Registers and labels are partially renamed to better reflect code actions. This patch is dependent on JDK-8218966 and should be applied on top of it. Testing: - jck - hotspot jtreg compiler/*, runtime/* and gc/* tests. Including AARCH64-implementation-specific compareTo tests introduced in JDK-8218966 fix - jdk jtreg tier1-3 tests No regressions were found. I'd like to thank Pengfei Li (Pengfei.Li(a)arm.com) for pre-review and additional testing. Thanks, Dmitrij

5 10

AARCH64 support for lworld
by Dmitry Samersoff 08 Sep '19

08 Sep '19

Hello Everybody, I started implementation of AARCH64 support for lworld. I'm on very early stage so any advices are highly appreciated. Should I file a CR for this task somewhere? What is correct way to do it? -Dmitry -- Dmitry Samersoff http://devnull.samersoff.net * There will come soft rains ...

6 28

RFR: 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3
by Nick Gasson 17 Jun '19

17 Jun '19

Hi, Please review this set of fixes to building hotspot with GCC 8.3 or Clang 7.0 on AArch64. Bug: https://bugs.openjdk.java.net/browse/JDK-8224851 Webrev: http://cr.openjdk.java.net/~ngasson/8224851/webrev.0/ Ran jtreg with no new failures. This first one is with GCC 8.3: /home/nicgas01/jdk/src/hotspot/cpu/aarch64/frame_aarch64.cpp: In function 'void pf(long unsigned int, long unsigned int, long unsigned int, long unsigned int, long unsigned int)': /home/nicgas01/jdk/src/hotspot/cpu/aarch64/frame_aarch64.cpp:775:35: error: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class RegisterMap' with no trivial copy-assignment; use copy-assignment or copy-initialization instead [-Werror=class-memaccess] memcpy(reg_map, &map, sizeof map); ^ RegisterMap is non-POD because its base class AllocatedObj has virtual methods, so we need to use copy-assignment rather than memcpy. But because we're allocating reg_map with os::malloc we ought to use placement new to properly construct it first. But we can't do that because RegisterMap inherits from StackObj which disallows new. So I just put in some casts to void * to silence the warning. I can't see where `pf' and `internal_pf' are used - perhaps they can be called manually from the debugger? If no one uses them maybe they should be deleted? The remaining warnings / errors are with Clang 7.0. /home/nicgas01/jdk/src/hotspot/cpu/aarch64/assembler_aarch64.hpp:279:22: error: & has lower precedence than ==; == will be evaluated first [-Werror,-Wparentheses] assert_cond(bits & mask == mask); ^~~~~~~~~~~~~~ To preserve the behaviour we should write `bits & (mask == mask)' but I don't think this was what was intended so I changed it to `(bits & mask) == mask'. /home/nicgas01/jdk/src/hotspot/cpu/aarch64/interp_masm_aarch64.hpp:44:25: error: redeclaration of using declaration using MacroAssembler::call_VM_leaf_base; ~~~~~~~~~~~~~~~~^ This using declaration appears twice in a row. /home/nicgas01/jdk/src/hotspot/cpu/aarch64/aarch64.ad:13866:80: error: invalid suffix 'D' on floating constant __ fcmps(as_FloatRegister(opnd_array(1)->reg(ra_,this,idx1)/* src1 */), 0.0D); ^ The "d" or "D" suffix on floating point literals is not in C++98. I believe it comes from an extension to C to support decimal floating point? Anyway it's not necessary here. /home/nicgas01/jdk/src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp:429:66: error: implicit conversion of NULL constant to 'bool' [-Werror,-Wnull-conversion] arithmetic_op_fpu(x->op(), reg, left.result(), right.result(), NULL); ~~~~~~~~~~~~~~~~~ ^~~~ false The NULL here is for the `bool is_strictfp' argument to LIRGenerator::arithmetic_op_fpu. Changing it to `false' would preserve the existing behaviour but it seems like it should be `x->is_strictfp()' to match other platforms. As a consequence of this we need to handle the lir_{div,mul}_scriptfp opcodes in LIR_Assembler::arith_op, but these just fall through to the non-strictfp variants so there should be no behaviour change. /home/nicgas01/jdk/src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp:1074:24: error: '&&' within '||' [-Werror,-Wlogical-op-parentheses] if (is_unordered && op->cond() == lir_cond_equal ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Added parenthesis to make this explicit. No behaviour change. /home/nicgas01/jdk/src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.s:162:32: error: index must be a multiple of 8 in range [0, 32760]. prfm pldl1keep, [s, #-256] ^ The immediate offset in `prfm' gets zero-extended to 64-bits and then left shifted three places so can only be unsigned. GNU as actually assembles [s, #-256] the same as [s]: 0: f9800000 prfm pldl1keep, [x0] Seems like GNU as ought to report an error here instead. I've replaced this with `prfum' which has a sign-extended offset. /home/nicgas01/jdk/src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.hpp:43:39: error: cannot initialize a parameter of type 'char *' with an lvalue of type 'unsigned long' return __sync_add_and_fetch(dest, add_value); ^~~~~~~~~ If the add_and_fetch template is instantiated with I=integer and D=pointer then we need an explicit cast here. /home/nicgas01/jdk/src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp:679:8: error: conflicting types for '_Copy_conjoint_jshorts_atomic' void _Copy_conjoint_jshorts_atomic(jshort* from, jshort* to, size_t count) { ^ This family of functions is declared with const `from' pointer but in the definition it is non-const. Made it const everywhere. /home/nicgas01/jdk/src/hotspot/cpu/aarch64/vm_version_aarch64.cpp:177:13: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses] if (p = strchr(buf, ':')) { ~~^~~~~~~~~~~~~~~~~~ Put parentheses around the argument. No functional change. /home/nicgas01/jdk/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp:2684:17: error: shifting a negative signed value is undefined [-Werror,-Wshift-negative-value] offset &= -1<<12; ~~^ Rewrote as ~((1<<12) - 1) which matches the masks used in the rest of the function. /home/nicgas01/jdk/src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp:103:20: error: variable 'esp' is uninitialized when used here [-Werror,-Wuninitialized] return (address) esp; ^~~ /home/nicgas01/jdk/src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp:101:21: note: initialize the variable 'esp' to silence this warning register void *esp __asm__ (SPELL_REG_SP); ^ = nullptr We could silence the -Wuninitialized warning for this function, but that doesn't help much because Clang then compiles os::current_stack_pointer() into: 0000000000000000 <_ZN2os21current_stack_pointerEv>: 0: d65f03c0 ret Whereas with GCC we get: 0000000000000250 <_ZN2os21current_stack_pointerEv>: 250: 910003e0 mov x0, sp 254: d65f03c0 ret Added some inline assembly to explicitly move sp into the result #ifdef __clang__. Same with _get_previous_fp(). Thanks, Nick

3 21

RFR: JDK-8214527 AArch64: ZGC for Aarch64
by Stuart Monteith 14 Jun '19

14 Jun '19

Hello, This patch implements ZGC for AArch64. Unlike the previous set of patches, this duplicates the x86 multimapping scheme rather than using the Aarch64 TBI feature, where the top 8 bits are ignored by the hardware. I didn't measure any conclusive performance problems using multimapping. It would necessitate changes to SA, JNI, and wasn't going to be compatible with Graal or JVMCI in general until they were also able to switch to 64-bit literals dynamically. In addition, there are up and coming features in the AArch64 architecture that exploit the TBI area that we should keep open, such as MTE (Memory Tagging Extensions) that open the door to lightweight hardware ASAN. With MTE using 4 of the 8 bits, and ZGC and MTE perhaps needing more than 4 bits, future conflict looks likely. JTreg testing hasn't demonstrated any significant differences from x86 ZGC in my testing. The behaviour should be the same as is expected from x86_64, including for the behaviour with command line arguments. Currently ZGC requires -XX:+UnlockExperimentalVMOptions, that should be the case for AArch64 this release. If x86_64 were to do have ZGC designated as not experimental, we must ensure it still applies for ZGC on AArch64. The associated bug is: https://bugs.openjdk.java.net/browse/JDK-8214527 The patchset is: http://cr.openjdk.java.net/~smonteith/8214527/webrev.0/ There is a patch contributed by Roland Westerlin required for fixing memory barriers, http://cr.openjdk.java.net/~smonteith/zgc-mm/20190430/membar/ I'll follow up with a separate RFR patch to address that. Thanks, Stuart

8 42

RFR: 8224828: aarch64: save and restore the rflags register in push_CPU_state and pop_CPU_state
by Yangfei (Felix) 13 Jun '19

13 Jun '19

Hi, Please review: JBS: https://bugs.openjdk.java.net/browse/JDK-8224828 Webrev: http://cr.openjdk.java.net/~fyang/8224828/webrev.00/ Currently, the rflags register is not handled in push_CPU_state and pop_CPU_state for the aarch64 port (including aarch64-8u, jdk11 and jdk13). This is causing random Hadoop Terasort failure using an aarch64-8u jvm. After some further investigation, we located the problematic C2 JIT code snippet: 1190 0x0000ffff785f8a1c: lsr x14, x15, x11 1191 0x0000ffff785f8a20: lsr x11, x6, x11 1192 0x0000ffff785f8a24: and x11, x11, #0xff 1193 0x0000ffff785f8a28: and x14, x14, #0xff 1194 0x0000ffff785f8a2c: sub x11, x14, x11 1195 0x0000ffff785f8a30: mov w14, w11 1196 0x0000ffff785f8a34: cmp w14, #0x0 1197 0x0000ffff785f8a38: cset w15, lt ;*invokeinterface compare 1198 ; - org.apache.hadoop.mapred.Merger$MergeQueue::lessThan@70 (line 658) 1199 ; - org.apache.hadoop.util.PriorityQueue::downHeap@41 (line 141) 1200 ; - org.apache.hadoop.util.PriorityQueue::adjustTop@1 (line 108) 1201 ; - org.apache.hadoop.mapred.Merger$MergeQueue::adjustPriorityQueue@59 (line 595) 1202 ; - org.apache.hadoop.mapred.Merger$MergeQueue::next@25 (line 618) 1203 1204 0x0000ffff785f8a3c: cmp w14, #0x0 <==================== 1205 0x0000ffff785f8a40: adrp x11, 0x0000ffff88830000 1206 ; {poll} 1207 0x0000ffff785f8a44: mov w17, w20 ; OopMap{r17=NarrowOop [32]=Oop [40]=Oop [56]=Oop [64]=Oop [80]=NarrowOop off=1224} 1208 ;*ifeq 1209 ; - org.apache.hadoop.util.PriorityQueue::downHeap@121 (line 149) 1210 ; - org.apache.hadoop.util.PriorityQueue::adjustTop@1 (line 108) 1211 ; - org.apache.hadoop.mapred.Merger$MergeQueue::adjustPriorityQueue@59 (line 595) 1212 ; - org.apache.hadoop.mapred.Merger$MergeQueue::next@25 (line 618) 1213 1214 0x0000ffff785f8a48: ldr wzr, [x11] ; {poll} <==================== 1215 0x0000ffff785f8a4c: csel w24, w12, w10, lt ;*invokevirtual compareTo <==================== 1216 ; - org.apache.hadoop.io.FastByteComparisons$LexicographicalComparerHolder$UnsafeComparer::compareTo@16 ( line 132) 1217 ; - org.apache.hadoop.io.FastByteComparisons::compareTo@11 (line 46) 1218 ; - org.apache.hadoop.io.WritableComparator::compareBytes@8 (line 188) 1219 ; - org.apache.hadoop.io.Text$Comparator::compare@39 (line 368) 1220 ; - org.apache.hadoop.mapred.Merger$MergeQueue::lessThan@70 (line 658) 1221 ; - org.apache.hadoop.util.PriorityQueue::downHeap@41 (line 141) 1222 ; - org.apache.hadoop.util.PriorityQueue::adjustTop@1 (line 108) 1223 ; - org.apache.hadoop.mapred.Merger$MergeQueue::adjustPriorityQueue@59 (line 595) 1224 ; - org.apache.hadoop.mapred.Merger$MergeQueue::next@25 (line 618) At line 1204, the rflags register is defined and it will be used at line 1215. There is a safepoint poll in between at line 1214. Safepoint is requested at line 1214 and control flow continues in the code generated by SafepointBlob* SharedRuntime::generate_handler_blob. This blob calls save_live_register and restore_live_registers which will finally calls push_CPU_state and pop_CPU_state. As the rflags register is not saved and restored by push_CPU_state and pop_CPU_state, we got an invalid rflags at line 1215. Patch fixes the issue for jdk13 by saving and restoring the rflags register in push_CPU_state and pop_CPU_state respectively. Thanks, Felix

4 9

hg: aarch64-port/jdk8u-shenandoah/hotspot: 8224828: aarch64: rflags is not correct after safepoint poll
by felix.yang＠huawei.com 31 May '19

31 May '19

Changeset: aa89ab331168 Author: fyang Date: 2019-05-31 15:51 +0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/aa89ab… 8224828: aarch64: rflags is not correct after safepoint poll Reviewed-by: aph, adinn Contributed-by: Xiang Yuan <yuanxiang4(a)huawei.com> ! src/cpu/aarch64/vm/aarch64.ad ! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp

1 0

JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64
by ci_notify＠linaro.org 30 May '19

30 May '19

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/jdkX/openjdk-jtreg-nightly-tests/summary/2019/149… ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/apr/22 pass: 5,580; fail: 2; not run: 96 Build 1: aarch64/2019/apr/24 pass: 5,579; fail: 3; not run: 96 Build 2: aarch64/2019/apr/26 pass: 5,579; fail: 3; error: 1; not run: 96 Build 3: aarch64/2019/apr/29 pass: 5,601; fail: 2; not run: 96 Build 4: aarch64/2019/may/01 pass: 5,602; fail: 2; not run: 96 Build 5: aarch64/2019/may/03 pass: 5,598; fail: 2; not run: 96 Build 6: aarch64/2019/may/06 pass: 5,598; fail: 2; not run: 96 Build 7: aarch64/2019/may/08 pass: 5,598; fail: 3; not run: 96 Build 8: aarch64/2019/may/15 pass: 5,600; fail: 2; error: 1; not run: 96 Build 9: aarch64/2019/may/17 pass: 5,619; fail: 4; not run: 96 Build 10: aarch64/2019/may/20 pass: 5,620; fail: 3; error: 1; not run: 96 Build 11: aarch64/2019/may/22 pass: 5,622; fail: 2; not run: 96 Build 12: aarch64/2019/may/24 pass: 5,625; fail: 3; not run: 96 Build 13: aarch64/2019/may/27 pass: 5,626; fail: 2; not run: 96 Build 14: aarch64/2019/may/29 pass: 5,623; fail: 4; not run: 96 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/apr/22 pass: 8,533; fail: 526; error: 25 Build 1: aarch64/2019/apr/24 pass: 8,521; fail: 531; error: 28 Build 2: aarch64/2019/apr/26 pass: 8,521; fail: 531; error: 28 Build 3: aarch64/2019/apr/29 pass: 8,527; fail: 527; error: 26 Build 4: aarch64/2019/may/01 pass: 8,533; fail: 528; error: 21 Build 5: aarch64/2019/may/03 pass: 8,501; fail: 552; error: 31 Build 6: aarch64/2019/may/06 pass: 8,547; fail: 516; error: 22 Build 7: aarch64/2019/may/08 pass: 8,545; fail: 520; error: 21 Build 8: aarch64/2019/may/15 pass: 8,528; fail: 539; error: 26 Build 9: aarch64/2019/may/17 pass: 8,543; fail: 534; error: 25 Build 10: aarch64/2019/may/20 pass: 8,552; fail: 525; error: 26 Build 11: aarch64/2019/may/22 pass: 8,554; fail: 531; error: 22 Build 12: aarch64/2019/may/24 pass: 8,548; fail: 536; error: 26 Build 13: aarch64/2019/may/27 pass: 8,580; fail: 511; error: 19 Build 14: aarch64/2019/may/29 pass: 8,563; fail: 527; error: 20 2 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/apr/22 pass: 3,936 Build 1: aarch64/2019/apr/24 pass: 3,937 Build 2: aarch64/2019/apr/26 pass: 3,938 Build 3: aarch64/2019/apr/29 pass: 3,938 Build 4: aarch64/2019/may/01 pass: 3,939 Build 5: aarch64/2019/may/03 pass: 3,940 Build 6: aarch64/2019/may/06 pass: 3,940 Build 7: aarch64/2019/may/08 pass: 3,940 Build 8: aarch64/2019/may/15 pass: 3,943 Build 9: aarch64/2019/may/17 pass: 3,944 Build 10: aarch64/2019/may/20 pass: 3,944 Build 11: aarch64/2019/may/22 pass: 3,944; fail: 1 Build 12: aarch64/2019/may/24 pass: 3,946 Build 13: aarch64/2019/may/27 pass: 3,946 Build 14: aarch64/2019/may/29 pass: 3,946 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 Previous results can be found here: http://openjdk.linaro.org/jdkX/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.80x Relative performance: Server critical-jOPS (nc): 9.36x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/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: 204.57 Server 204.57 / Server 2014-04-01 (71.00): 2.88x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-04-22 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/112/results/ 2019-04-24 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/114/results/ 2019-04-26 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/116/results/ 2019-04-29 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/119/results/ 2019-05-01 pass rate: 11559/11559, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/121/results/ 2019-05-03 pass rate: 11559/11559, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/123/results/ 2019-05-06 pass rate: 11559/11559, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/126/results/ 2019-05-08 pass rate: 11559/11559, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/128/results/ 2019-05-15 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/135/results/ 2019-05-18 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/137/results/ 2019-05-20 pass rate: 10487/10488, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/140/results/ 2019-05-22 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/142/results/ 2019-05-24 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/144/results/ 2019-05-27 pass rate: 10487/10488, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/147/results/ 2019-05-30 pass rate: 10487/10488, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/149/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/

1 0

hg: aarch64-port/jdk8u-shenandoah/hotspot: 2 new changesets
by aph＠redhat.com 29 May '19

29 May '19

Changeset: 1bbf357c0164 Author: aph Date: 2019-05-28 09:03 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/1bbf35… 8224671: AArch64: mauve System.arraycopy test failure Reviewed-by: adinn ! src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp Changeset: a31ff0acf39b Author: aph Date: 2019-05-28 11:15 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/a31ff0… 8224880: AArch64: java/javac error with AllocatePrefetchDistance Reviewed-by: adinn ! src/cpu/aarch64/vm/vm_version_aarch64.cpp

1 0

[8u] RFR: 8224671: AArch64: mauve System.arraycopy test failure
by Andrew Haley 28 May '19

28 May '19

Patch applies cleanly. https://bugs.openjdk.java.net/browse/JDK-8224671 http://cr.openjdk.java.net/~aph/8224671/jdk-test.changeset -- Andrew Haley 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

[8u-aarch64] RFR/RFC 8186325: AArch64: jtreg test hotspot/test/gc/g1/TestJNIWeakG1/TestJNIWeakG1.java SEGV
by Aleksey Shipilev 28 May '19

28 May '19

Recent backport of JNI Weak handling in G1: https://bugs.openjdk.java.net/browse/JDK-8176100 ...brought the problem, which we detected when doing Shenandoah testing. We have the gc/shenandoah/jni/TestJNIGlobalRefs.sh test that breaks on AArch64 with the attempted fix of JNI Weak there: https://mail.openjdk.java.net/pipermail/shenandoah-dev/2019-May/009770.html The trouble is already fixed in 10+: https://bugs.openjdk.java.net/browse/JDK-8186325 https://hg.openjdk.java.net/jdk10/jdk10/hotspot/rev/3a8e8737cb36 ...and we need to backport it. The fix is aarch64-specific, and so does not apply to 8u upstream. This is not Shenandoah-specific failure: G1 should fail the same way, but only Shenandoah tests capture it. The fix does not apply cleanly, because there are Shenandoah changes nearby. Webrev for aarch64-port/jdk8u-shenandoah/hotspot: https://cr.openjdk.java.net/~shade/8186325/webrev.8u-aarch64.01/ Testing: hotspot_gc_shenandoah on aarch64 (used to fail, now it passes) -- Thanks, -Aleksey

3 4