March 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

[Roland Westrelin] Re: Aarch64 port for ZGC, so far
by Roland Westrelin 24 May '19

24 May '19

Just noticed I didn't include the mailing lists in that reply. Roland.

7 43

8218966: AArch64: String.compareTo() can read memory after string
by Dmitrij Pochepko 20 May '19

20 May '19

Hi all, Please review a fix for "8218966: AArch64: String.compareTo() can read memory after string". bug: https://bugs.openjdk.java.net/browse/JDK-8218966 webrev: http://cr.openjdk.java.net/~dpochepk/8218966/webrev/ Intrinsic implementation returns wrong value in rare cases for strings longer than 72 characters. Changes: - Different encodings case. Small 16-characters loop and post-loop code are re-organized to stop at string end. Post-loop now also uses compare_string_16_x_LU() to avoid code duplication. - Changed calculation of prefetchLoopExitCondition. It might be incorrect in case when SoftwarePrefetchHintDistance was set to non-default small value. - Same encoding case. Moved loop counter update out of prefetch block. It might miss end-of-string check when prefetch is disabled, with memory after string being read. - Added 2 tests. They are quite similar but TestStringCompareToSameLength compares strings of same length, and TestStringCompareToDifferentLength is for different lengths. Tests cover 8218966 case. And also they cover different parts of intrinsic, taking into account conditions in the implementation and possible SoftwarePrefetchHintDistance values. Testing: Existing jtreg and jck tests were not able to detect 8218966 case. But they pass with the fix applied. Newly added jtreg tests can detect the issue and potential problems in case of changes in the implementation. The following testing was performed: - jck with default vm flags - jck with -Xcomp -XX:-TieredCompilation - hotspot jtreg tests (including new tests): compiler/*, runtime/*, gc/* with default vm flags - hotspot jtreg tests (including new tests): compiler/*, runtime/*, gc/* with -Xcomp -XX:-TieredCompilation - jdk jtreg tier1-3 tests with default vm flags - jdk jtreg tier1-3 tests with -Xcomp -XX:-TieredCompilation No regressions were found. I'd like to thank Pengfei Li (Pengfei.Li(a)arm.com) for pre-review and additional testing. I'm also about to send separate additional webrev with compareTo intrinsic documentation and maintenance-related improvements as separate enhancement. Thanks, Dmitrij

2 1

Re: [aarch64-port-dev ] RFR(S): 8215792: AArch64: String.indexOf generates incorrect result
by Pengfei Li (Arm Technology China) 19 May '19

19 May '19

Hi Dmitrij, Thanks a lot for your reply. > since cnt2 is used as counter, wouldn't it be easier and shorter just to substract cnt1 from cnt2 at the beginning of this code. Total (cnt2 - cnt1 +1) combinations must be checked. That is why first sustraction is by (wordSize/str2_chr_size - 1). > Then whole fix will be probably just 1 line at the beginning: sub(cnt2, cnt2, cnt1); I don't think the whole fix could be as easy as "sub(cnt2, cnt2, cnt1)" because cnt2 is the counter which counts number of bytes not processed. It could be different from the number of bytes after current first-character-match index. But this is just my thought. Perhaps I didn't understand your idea and code thoroughly. So could you post your shorter fix and let's test if it's right? -- Thanks, Pengfei

6 14

RFR: RFR: Bulk integration shenandoah/jdk8u -> aarch64-port/jdk8u-shenandoah 2018-12-13
by Roman Kennke 29 Apr '19

29 Apr '19

Please review the following proposed changes: This integrates changes from shenandoah/jdk8u into aarch64-port/jdk8u-shenandoah repository, reaching back to September 2018. It's bugfixes, improvements and new features that have been originally done in Shenandoah dev repo, and then backported to Shenandoah JDK8u repo and tested there for a while too. List of changes: http://cr.openjdk.java.net/~rkennke/jdk8u-shenandoah-integration-2018-12-13… Webrev showing only shared-changes: http://cr.openjdk.java.net/~rkennke/jdk8u-shenandoah-integration-2018-12-13… Full webrev: http://cr.openjdk.java.net/~rkennke/jdk8u-shenandoah-integration-2018-12-13… Thanks, Roman

5 15

RFR: 8221658: aarch64: add necessary predicate for ubfx patterns
by Yangfei (Felix) 09 Apr '19

09 Apr '19

Hi, Please review this patch adding necessary predicate for ubfx patterns in aarch64.ad. Bug: https://bugs.openjdk.java.net/browse/JDK-8221658 Webrev: http://cr.openjdk.java.net/~fyang/8221658/webrev.00 Currently, this issue is only reproduced with an aarch64 8u jdk. Although it is not reproduced with aarch64 jdk11 or newer versions, it's better for them to have this fix. Jtreg tested with aarch64 jdk8u & jdk13 fastdebug build. Also passed the private fuzz test. Thanks, Felix

2 10

RFR (XS) 8221725: AArch64 build failures after JDK-8221408 (Windows 32bit build build errors/warnings in hotspot)
by Aleksey Shipilev 03 Apr '19

03 Apr '19

Bug: https://bugs.openjdk.java.net/browse/JDK-8221725 Fix: diff -r f062188117ad src/hotspot/cpu/aarch64/aarch64.ad --- a/src/hotspot/cpu/aarch64/aarch64.ad Sat Mar 30 21:29:37 2019 +0100 +++ b/src/hotspot/cpu/aarch64/aarch64.ad Sun Mar 31 23:30:41 2019 +0200 @@ -3443,11 +3443,11 @@ // Check if the owner is self by comparing the value in the // markOop of object (disp_hdr) with the stack pointer. __ mov(rscratch1, sp); __ sub(disp_hdr, disp_hdr, rscratch1); - __ mov(tmp, (address) (~(os::vm_page_size()-1) | markOopDesc::lock_mask_in_place)); + __ mov(tmp, (address) (~(os::vm_page_size()-1) | (uintptr_t)markOopDesc::lock_mask_in_place)); // If condition is true we are cont and hence we can store 0 as the // displaced header in the box, which indicates that it is a recursive lock. __ ands(tmp/*==0?*/, disp_hdr, tmp); // Sets flags for result The offending change pulled some enum constants out, which apparently made enum representation much smaller. Not sure if putting the constants back does not break Win32 build again. So, instead, fix it up in one place that blows up with build warning-as-error. The fix has some level of ewwness, but it seems to be the same as what bytecodeInterpreter.cpp is doing. The alternative is to cast to uintx, as macroAssembler_arm.cpp is doing. Testing: Linux aarch64 fastdebug build, ad-hoc tests -- Thanks, -Aleksey

6 7

RFR: 8217368: AArch64: C2 recursive stack locking optimisation not triggered
by Nick Gasson (Arm Technology China) 03 Apr '19

03 Apr '19

Hi, While I was cleaning up the patch for 8216350 I noticed an issue in the implementation of recursive locking in aarch64_enc_fast_lock: Bug: https://bugs.openjdk.java.net/browse/JDK-8217368 Webrev: http://cr.openjdk.java.net/~ngasson/8217368/webrev.0/ First we load the markOop of the object we want to lock and OR it with markOopDesc::unlocked_value (1). Then we do a CAS to exchange the address of the box on our thread's stack with the object's header word iff it's equal to the (markOop | 1) we just computed. If this fails, then we should check for a recursive lock by comparing (~(page size - 1) | 3) & (markOop - SP) == 0 Where "markOop" is the current object header word loaded by the failed CAS. This checks that the lock bits are zero (locked) and the stack address of the displaced header is within one page of the current SP. But on AArch64 we actually do this: (~(page size - 1) | 3) & ((old markOop | 1) - SP) == 0 Where "old markOop | 1" is the compare-to value used for the CAS. This is always false as the result has at least bit #0 set. This only affects C2, the C1_MacroAssembler version has the correct test. The diff looks big but all it does is swap the usage of registers `tmp' and `disp_hdr' in the first section so the markOop loaded by the CAS ends up in disp_hdr and tmp holds the (markOop | 1) compare-to value. Ran jtreg, plus jcstress with -XX:+UseLSE and -XX:-UseLSE. Also added another microbenchmark to micro/org/openjdk/bench/vm/lang/LockUnlock.java as I couldn't find an existing JMH case that triggered this. Without patch: Result "org.openjdk.bench.vm.lang.LockUnlock.testRecursiveSynchronizationNoBias": 510.781 ?(99.9%) 1.196 ns/op [Average] (min, avg, max) = (508.769, 510.781, 513.854), stdev = 1.597 CI (99.9%): [509.585, 511.977] (assumes normal distribution) With patch: Result "org.openjdk.bench.vm.lang.LockUnlock.testRecursiveSynchronizationNoBias": 197.038 ?(99.9%) 0.096 ns/op [Average] (min, avg, max) = (196.886, 197.038, 197.296), stdev = 0.128 CI (99.9%): [196.942, 197.134] (assumes normal distribution) Two other minor things: * Does anyone know what the comment "// Load Compare Value application register." means? It's present in the PPC and S390 ports too. * The x86 port #ifdef LP64 uses "7 - os::vm_page_size()" as the mask in the recursive lock test. I think the "7" here is markOopDesc::biased_lock_mask and is presumably there to prevent a silent mutual exclusion failure if a markOop with the bias locking bits set ends up the fast_lock path (although this should never happen). Should we change markOopDesc::lock_mask_in_place to markOopDesc::biased_lock_mask_in_place in the AArch64 port too? Thanks, Nick

4 14

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

29 Mar '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/088… ------------------------------------------------------------------------------- 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/feb/15 pass: 5,538; fail: 4; not run: 93 Build 1: aarch64/2019/feb/18 pass: 5,538; fail: 4; not run: 93 Build 2: aarch64/2019/feb/20 pass: 5,539; fail: 4; not run: 93 Build 3: aarch64/2019/feb/25 pass: 5,540; fail: 4; not run: 93 Build 4: aarch64/2019/feb/27 pass: 5,541; fail: 4; not run: 93 Build 5: aarch64/2019/mar/01 pass: 5,541; fail: 4; not run: 93 Build 6: aarch64/2019/mar/04 pass: 5,540; fail: 4; error: 1; not run: 93 Build 7: aarch64/2019/mar/06 pass: 5,544; fail: 3; not run: 93 Build 8: aarch64/2019/mar/08 pass: 5,546; fail: 3; not run: 93 Build 9: aarch64/2019/mar/11 pass: 5,547; fail: 3; not run: 93 Build 10: aarch64/2019/mar/13 pass: 5,549; fail: 3; not run: 93 Build 11: aarch64/2019/mar/15 pass: 5,567; fail: 3; not run: 93 Build 12: aarch64/2019/mar/18 pass: 5,568; fail: 3; not run: 93 Build 13: aarch64/2019/mar/20 pass: 5,568; fail: 3; not run: 93 Build 14: aarch64/2019/mar/29 pass: 5,572; fail: 3; not run: 93 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/feb/15 pass: 8,556; fail: 492; error: 16 Build 1: aarch64/2019/feb/18 pass: 8,530; fail: 514; error: 20 Build 2: aarch64/2019/feb/20 pass: 8,550; fail: 498; error: 17 Build 3: aarch64/2019/feb/25 pass: 8,535; fail: 510; error: 23 Build 4: aarch64/2019/feb/27 pass: 8,538; fail: 513; error: 20 Build 5: aarch64/2019/mar/01 pass: 8,554; fail: 499; error: 20 Build 6: aarch64/2019/mar/04 pass: 8,521; fail: 527; error: 20 Build 7: aarch64/2019/mar/06 pass: 8,541; fail: 506; error: 21 Build 8: aarch64/2019/mar/08 pass: 8,538; fail: 512; error: 20 Build 9: aarch64/2019/mar/11 pass: 8,531; fail: 520; error: 19 Build 10: aarch64/2019/mar/13 pass: 8,533; fail: 514; error: 22 Build 11: aarch64/2019/mar/15 pass: 8,519; fail: 513; error: 23 Build 12: aarch64/2019/mar/18 pass: 8,510; fail: 523; error: 24 Build 13: aarch64/2019/mar/20 pass: 8,513; fail: 522; error: 25 Build 14: aarch64/2019/mar/29 pass: 8,519; fail: 532; error: 22 3 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/feb/15 pass: 3,995 Build 1: aarch64/2019/feb/18 pass: 3,996 Build 2: aarch64/2019/feb/20 pass: 3,996 Build 3: aarch64/2019/feb/25 pass: 3,931 Build 4: aarch64/2019/feb/27 pass: 3,931 Build 5: aarch64/2019/mar/01 pass: 3,931 Build 6: aarch64/2019/mar/04 pass: 3,931 Build 7: aarch64/2019/mar/06 pass: 3,931 Build 8: aarch64/2019/mar/08 pass: 3,931 Build 9: aarch64/2019/mar/11 pass: 3,931 Build 10: aarch64/2019/mar/13 pass: 3,931 Build 11: aarch64/2019/mar/15 pass: 3,932 Build 12: aarch64/2019/mar/18 pass: 3,932 Build 13: aarch64/2019/mar/20 pass: 3,933 Build 14: aarch64/2019/mar/29 pass: 3,935 ------------------------------------------------------------------------------- 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.63x Relative performance: Server critical-jOPS (nc): 9.30x 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: 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/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-02-15 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/046/results/ 2019-02-18 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/049/results/ 2019-02-20 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/051/results/ 2019-02-25 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/056/results/ 2019-02-27 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/058/results/ 2019-03-01 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/060/results/ 2019-03-04 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/063/results/ 2019-03-06 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/065/results/ 2019-03-08 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/067/results/ 2019-03-11 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/070/results/ 2019-03-13 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/072/results/ 2019-03-15 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/074/results/ 2019-03-18 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/077/results/ 2019-03-20 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/079/results/ 2019-03-29 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/088/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/

1 0