August 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

Re: [aarch64-port-dev ] RFR: [8u] 8209835: Aarch64: elide barriers on all volatile operations
by Yangfei (Felix) 31 Oct '19

31 Oct '19

On 8/28/19 10:18 AM, Yangfei (Felix) wrote: >> Well, I think I won't be able to provide such a test case after some >> throughts. Now I agree that this will not affect basic functionality. >> As we have handled unsafe.compareAndSwap, I don't see a reason to not >> handle unsafe.getAndSet: the risk should be low and we get consistent >> and improved C2 JIT code. What do you think? > I think that's a powerful argument for the development code because it's an improvement; conversely I don't think it's an argument for a backport. > Having said that, I can sort-of imagine a jcstress failure if we had a test that was doing compareAndSwap in one thread and getAndSet in another. That would be a seriously compelling reason for a backport! Can you elaborate more please? especially the possible code sequence. Currently, we have C2 JIT for getAndSet like this: 33 ;; membar_release 34 0x0000ffffa416ae74: dmb ish 35 ;; 0x40000000000 36 0x0000ffffa416ae78: orr x11, xzr, #0x40000000000 37 0x0000ffffa416ae7c: add x10, x1, #0x10 38 0x0000ffffa416ae80: prfm pstl1strm, [x10] 39 0x0000ffffa416ae84: ldxr x9, [x10] 40 0x0000ffffa416ae88: stxr w8, x11, [x10] 41 0x0000ffffa416ae8c: cbnz w8, 0x0000ffffa416ae84 42 0x0000ffffa416ae90: mov x10, x9 43 ;; membar_acquire 44 0x0000ffffa416ae94: dmb ishld ;*invokevirtual getAndSetLong I think the two dmb instructions at the head and tail should ensure the consistency. Isn't it? > It would be interesting to see such a jcstress test. Even if the test does not fail, we could look at the generated code to see if it might fail according to the Arm memory model.

3 11

RFR: [8u] JDK-8211320: AArch64: unsafe.compareAndSetByte() and unsafe.compareAndSetShort() c2 intrinsics broken with negative expected value
by Andrew Dinn 09 Sep '19

09 Sep '19

I was asked to look at backporting this patch to jdk8u-shenandoah. However, I don't believe a backport is appropriate. The patch updates ad file encodings and associated assembler cmpxchg method code for rules that match CompareAndExchangeB/S and CompareAndSwapB/S. Those cases do not apply to jdk8u where there are no CompareAndExchange rules and CompareAndSwap rules are only defined for I/L/N/P. I'm bery happy to be corrected if I am missing something. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

3 4

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: [8u] JDK-8219006: AArch64: Register corruption in slow subtype check
by Andrew Dinn 29 Aug '19

29 Aug '19

I would like permission to backport JDK-8219006 to the aarch64 jdk8u-shenandoah repo. JIRA: https://bugs.openjdk.java.net/browse/JDK-8219006 The upstream jdk11u patch applies cleanly Why: The patch does not affect product code but it can cause a crash in debug builds. Testing: tier1 tests complete as before (modulo two tests that timed out before patching but completed successfully within the allotted time after patching -- I was running other jobs in the before case). regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

2 1

Re: [aarch64-port-dev ] RFR: [8u] 8209835: Aarch64: elide barriers on all volatile operations
by Yangfei (Felix) 28 Aug '19

28 Aug '19

>> Volatile access inconsistency still exists for some unsafe operations. One example is AtomicReference. >> For the volatile field 'value', compareAndSet() method accesses it through unsafe.compareAndSwapObject(). >> And getAndSet() method accessed it through unsafe.getAndSetObject(). >> Currently, C2 will emit ldar & stlr to implement unsafe.compareAndSwapObject(), but that is not the case for unsafe.getAndSetObject(). >> >> C2 still emits explicit dmb instructions to implement unsafe.getAndSetObject(). > I am not convinced. Please provide me with a test case of incorrect behaviour. Well, I think I won't be able to provide such a test case after some throughts. Now I agree that this will not affect basic functionality. As we have handled unsafe.compareAndSwap, I don't see a reason to not handle unsafe.getAndSet: the risk should be low and we get consistent and improved C2 JIT code. What do you think? Thanks, Felix

2 1

RFR: [8u] JDK-8219006: AArch64: Register corruption in slow subtype check
by Andrew Dinn 28 Aug '19

28 Aug '19

I would like permission to backport JDK-8219006 to the aarch64 jdk8u-shenandoah repo. JIRA: https://bugs.openjdk.java.net/browse/JDK-8219006 The upstream jdk11u patch applies cleanly Why: The patch does not affect product code but it can cause a crash in debug builds. Testing: tier1 tests complete as before (modulo two tests that timed out before patching but completed successfully within the allotted time after patching -- I was running other jobs in the before case). regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

1 0

RFR: [8u] 8209835: Aarch64: elide barriers on all volatile operations
by Yangfei (Felix) 28 Aug '19

28 Aug '19

Hi, Could I have a review for this backport to aarch64 8u repo please? Webrev: http://cr.openjdk.java.net/~fyang/8209835-8u-backport/webrev.00/ Changes related to CompareAndExchange* and WeakCompareAndSwap* in the original patch are not needed for the aarch64 8u repo. Volatile access inconsistency still exists for some unsafe operations. One example is AtomicReference. For the volatile field 'value', compareAndSet() method accesses it through unsafe.compareAndSwapObject(). And getAndSet() method accessed it through unsafe.getAndSetObject(). Currently, C2 will emit ldar & stlr to implement unsafe.compareAndSwapObject(), but that is not the case for unsafe.getAndSetObject(). C2 still emits explicit dmb instructions to implement unsafe.getAndSetObject(). Jtreg tested with aarch64 fastdebug build. Also passed jcstress test. Corresponding 11u backport link: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-August/001740.… Thanks, Felix

2 1

hg: aarch64-port/jdk8u-shenandoah/hotspot: 8216350: AArch64: monitor unlock fast path not called
by adinn＠redhat.com 27 Aug '19

27 Aug '19

Changeset: c99ce621059e Author: ngasson Date: 2019-08-27 15:54 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/c99ce… 8216350: AArch64: monitor unlock fast path not called Reviewed-by: aph, drwhite, fyang ! src/cpu/aarch64/vm/aarch64.ad ! src/cpu/aarch64/vm/assembler_aarch64.hpp

1 0

RFR: [8u] JDK-8216350: AArch64: monitor unlock fast path not called
by Andrew Dinn 27 Aug '19

27 Aug '19

Could I please have a review of the following backport to the aarch64 jdk8u-shenandoah repo. JIRA: https://bugs.openjdk.java.net/browse/JDK-8216350 webrev: http://cr.openjdk.java.net/~adinn/8220668-jdk8u/webrev.00 The original patch failed to apply properly (after adjusting the file paths) because of 3 minor differences: 1) jdk8u-shenandoah aarch64.ad had tabs instead of spaces in some deleted lines 2) jdk8u-shenandoah aarch64.ad references VM_Version::cpu_cpuFeatures in both deleted and new lines where upstrema code references VM_Version::features 3) jdk8u-shenandoah assembler_aarch64.hpp omits a comment that gets matched in the upstream code (// rscratch1 is zero) Testing: tier1 tests succeed as before regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

2 1