October 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

RFR: 8229351: AArch64: Make the stub threshold of string_compare intrinsic tunable
by Patrick Zhang OS 15 Nov '19

15 Nov '19

Hi, Could you please review this patch, thanks. JBS: https://bugs.openjdk.java.net/browse/JDK-8229351 Webrev: http://cr.openjdk.java.net/~qpzhang/8229351/webrev.02 (this starts from .02 since there had been some internal review and updates) Changes: 1. Split the STUB_THRESHOLD from the hard-coded 72 to be CompareLongStringLimitLatin and CompareLongStringLimitUTF as a more flexible control over the stub thresholds for string_compare intrinsics, especially for various uArchs. 2. MacroAssembler::string_compare LL and UU shared the same threshold, actually UU may only require the half (length of chars) of that of LL's, because one character has two-bytes for UU, while for compacted LL strings, one character means one byte. In addition, LU/UL may need a separated threshold, as the stub function is different from the same encoding one, and the performance may vary as well. 3. In generate_compare_long_string_same_encoding, the hard-coded 72 was originally able to ensure that there can be always 64 bytes at least for the prefetch code path. However once a smaller stub threshold is set, a new condition is needed to tell if this would be still valid, or has to go to the NO_PREFETCH branch. This change can ensure the correctness. 4. In generate_compare_long_string_different_encoding, some temp vars for handling the last 4 characters are not valid any longer, cleaned up strU and strL, and related pointers initialization to the next U (cnt1) and L (tmp2). 5. In compare_string_16_x_LU, the reference to r10 (tmp1) is not needed, as tmpU or tmpL point to the same register. Tests: 1. For function check, I have run jdk jtreg tier1 tests, with default vm flags hotspot jtreg tests: runtime/compiler/gc parts, with "-Xcomp -XX:-TieredCompilation" jck10/api/java.lang 1609 cases and other selected modules, no new failures found, with default vm flags and "-Xcomp -XX:-TieredCompilation" respectively; some specific test cases had been carefully executed to double check, i.e., TestStringCompareToDifferentLength.java [1] and TestStringCompareToDifferentLength.java [1] introduced by [2], StrCmpTest.java [3] introduced by [4]. 1. For performance check, I have run string-density-bench/CompareToBench.java [5] and StringCompareBench.java [6] respectively, and SPECjbb2015.jar, no obvious performance change has been found (since the default threshold is NOT changed within this patch). FYI. with Ampere eMAG system, microbenchmarks [5][6] can have 1.5x consistent perf gain with LU/UL comparison for shorter strings (<72 chars, smaller stub thresholds), and slight improvement (5~10%) with LL/UU cases. Refs: [1] http://hg.openjdk.java.net/jdk/jdk/file/3df2bf731a87/test/hotspot/jtreg/com… [2] https://bugs.openjdk.java.net/browse/JDK-8218966 AArch64: String.compareTo() can read memory after string [3] http://cr.openjdk.java.net/~dpochepk/8202326/StrCmpTest.java, contributed by Dmitrij Pochepko [4] https://bugs.openjdk.java.net/browse/JDK-8202326 AARCH64: optimize string compare intrinsic [5] http://cr.openjdk.java.net/~shade/density/string-density-bench.jar, contributed by Aleksey Shipilev [6] http://cr.openjdk.java.net/~dpochepk/8202326/StringCompareBench.java, contributed by Dmitrij Pochepko Regards Patrick

4 12

RFR 8233339: Shenandoah: Centralize load barrier decisions into ShenandoahBarrierSet
by Zhengyu Gu 07 Nov '19

07 Nov '19

Right now, the decisions on, if a load barrier needs load reference barrier, if so, what kind? and if the reference needs to be kept alive, are scattered inside interpreter/c1/2 load barrier code, which is hard to make them consistent. I would like to centralize the decision making into ShenandoahBarrierSet, so them can be consistent and easy to maintain. Bug: https://bugs.openjdk.java.net/browse/JDK-8233339 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8233339/webrev.00/index.html Test: hotspot_gc_shenandoah (fastdebug and release) x86_64 and x86_32 on Linux AArch64 on Linux Thanks, -Zhengyu

4 7

RFR (trivial) : fix aarch64-8u type profile bug
by Yangfei (Felix) 07 Nov '19

07 Nov '19

Hi, When I play with a simple test case (InstanceOfExample.java), I witnessed strange C2 JIT code generated by aarch64-8u: 000 B1: # B9 B2 <- BLOCK HEAD IS JUNK Freq: 1 000 # stack bang size=48 sub sp, sp, #48 stp rfp, lr, [sp, #32] 014 ldr R10, [R1, #8] # class 018 NullCheck R1 018 018 B2: # B8 B3 <- B1 Freq: 0.999999 018 + mov R4, precise klass MotorCycle: 0x0000ffff7c069030:Constant:exact * # ptr < ============== 024 + cmp R10, R4 // ptr < ============== 028 bne B8 # unsigned P=0.000000 C=-1.000000 < ============== 028 02c B3: # B6 B4 <- B2 Freq: 0.999999 02c + ldr R10, [R4, #32] # class 030 + mov R0, precise klass DriveCar: 0x0000ffff7c06a750:Constant:exact * # ptr 03c + cmp R10, R0 // ptr 040 bne B6 # unsigned P=0.170000 C=-1.000000 …… 0b0 B8: # N1 <- B2 Freq: 1e-35 0b0 + spill R1 -> [sp, #0] # spill size = 64 0b4 + mov R1, #-34 # int 0b8 call,static 0x0000ffff8979efc0 // ==> wrapper for: uncommon_trap(reason='class_check' action='maybe_recompile') # InstanceOfExample::instanceOfDriverCar @ bci:1 L[0]=_ STK[0]=sp + #0 # OopMap{[0]=Oop off=188} 0bc ShouldNotReachHere Here, C2 inserts an uncommon trap in B2 if the incoming parameter ‘o’ of instanceOfDriverCar method is not an instance of MotorCycle. As we send three different types of objects to instanceOfDriverCar method, this JIT code is not expected. The uncommon trap happens after Thread.sleep in main when instanceOfDriverCar got a Car object. GDB shows that profile_has_unique_klass gives a wrong result: profile.morphism() equals 1, but it should be 2 here, and this misleads the C2 compiler. I found this bug is fixed in: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/22fd02fad88b Fix for aarch64-8u is trivial: diff -r a1986eb5d5fd src/cpu/aarch64/vm/interp_masm_aarch64.cpp --- a/src/cpu/aarch64/vm/interp_masm_aarch64.cpp Mon Sep 09 18:54:16 2019 +0200 +++ b/src/cpu/aarch64/vm/interp_masm_aarch64.cpp Fri Sep 20 11:09:10 2019 +0800 @@ -1163,12 +1163,12 @@ b(done); bind(found_null); } else { - cbz(reg2, done); + cbnz(reg2, done); } break; } // Since null is rare, make it be the branch-taken case. - cbz(reg2,found_null); + cbz(reg2, found_null); // Put all the "Case 3" tests here. record_klass_in_profile_helper(receiver, mdp, reg2, start_row + 1, done, is_virtual_call); Is it OK to go? Thanks. Command line: java -XX:+UseSerialGC -Xms128M -Xmx128M -XX:-UseCompressedOops -XX:-UseCompressedClassPointers -XX:CICompilerCount=2 -XX:+PrintCompilation -XX:-TieredCompilation -XX:LoopMaxUnroll=0 -XX:CompileOnly=InstanceOfExample::instanceOfDriverCar -XX:-Inline -XX:+UnlockDiagnosticVMOptions -XX:+PrintOptoAssembly InstanceOfExample InstanceOfExample.java: public class InstanceOfExample { public static int count = 0; public static void main(String[] args) throws Exception { Vehicle vehicle = new Vehicle(); Car car = new Car(); MotorCycle moto = new MotorCycle(); Object[] tools = new Object[]{vehicle, car, moto}; for (int i = 0; i < 20000; i++) { if (instanceOfDriverCar(tools[i % 3])) { count++; } } Thread.sleep(2000); if (instanceOfDriverCar(car)) { count++; } } public static boolean instanceOfDriverCar(Object o) { if (o instanceof DriveCar) { return true; } return false; } } class Vehicle { } class Car extends Vehicle implements DriveCar { } class MotorCycle extends Vehicle { } interface DriveCar { }

2 9

RFD: scratch registers cleanup [Long post]
by Andrew Haley 06 Nov '19

06 Nov '19

[TL, DR: A large patch to clean up the use of scratch registers in the AArch64 port. Anyone who has ever written assembly code for the AArch64 port should probably read this.] In AArch64 HotSpot we reserve two scratch registers for general use and especially for use in macros. When we first wrote the port things were fairly simple: low-level assembler macros would use these registers freely and any macro that calls a macro would have to be aware that rscratch1 and rscratch2 would be clobbered. However, things haven't quite worked out that way. In practice people "know" that the macro WhizzyMacro they're using only clobbers rscratch1 and so rscratch2 will be "safe" and its contents will be preserved across WhizzyMacro. The danger of this is obvious: a maintenance programmer less familiar with the code base will come along and use some other registers. This is particularly problematic when a macro is used in many places, and if there are several versions of a macro, as happens in the case of GC barriers. There is another risk: aliasing, the extreme sport of referring to the same register in a macro by more than one name. Again, the risk is obvious: the poor programmer won't know that the registers "tmp" and "rscratch2" are in fact the same register. And there is the most excitingly risky practice of all, where an input operand to WhizzyMacro is passed in one of the scratch registers *by a different name* and WhizzyMacro also freely uses the same scratch register by its generic name. This has caused some programmers to confuse themselves about the code they were writing *while they were writing it*. Please do not do this. It is the road to perdition. Bear in mind that it is sometimes convenient to avoid declaring scratch registers in macros altogether. You can do this by passing all of the temporary registers a macro needs explicitly as arguments, and this can make the code smaller and simpler. Despite all of the foregoing, I still believe that reserving a couple of scratch registers was a good idea, but we need to clarify rules of ownership so that it is always clear to the reader who "owns" which scratch registers. Sometimes this is informally documented in comments, often not. I propose to mitigate this problem by removing the global declarations of rscratch1 and rscratch2 altogether and instead requiring them to be declared at the point of use. The Assembler will keep track of which registers are in use and which are free. For example, to use rscratch1 declare it thusly: ScratchRegister rscratch1(__ as(), r8); After this declaration rscratch1 may be used until the end of the innermost enclosing scope, like so: { ScratchRegister rscratch1(__ as(), r8); __ ldrb(rscratch1, gc_state); __ tbz(rscratch1, ShenandoahHeap::MARKING_BITPOS, done); } [NB: it is possible to give the scratch register a name other than rscratch1, but please don't!] Let's say you need to call InnerMacro from WhizzyMacro, and both InnerMacro and WhizzyMacro need scratch registers. You can do this by explicitly freeing the scratch registers, like so: WhizzyMacro() { ... ScratchRegister rscratch1(__ as(), r8); // Code using rscratch1 ... { FreeScratchRegs dummy(__ as()); __ InnerMacro(); // Try to use rscratch1 here and you'll get an assertion // because you don't own it. } // You can use rscratch1 again here. ... } In this case it is clear to the reader that InnerMacro() may clobber both scratch registers. At the end of the scope of FreeScratchRegs, rscratch1 is again owned by WhizzyMacro. I've written a prototype of this idea which does not (intentionally) change any of the generated code, it just documents what it does, and it enforces it. Anyone who uses a register way which conflicts with what has been declared will get an assertion failure. In a few special cases in this prototype I haven't attempted to use the new syntax. The interpreter has its own convention for register usage so scattering ScratchRegister declarations wouldn't much help. Likewise in aarch64.ad: many instruction patterns wouldn't benefit from such declarations because scratch registers are always free to use in patterns, but be careful if the patterns call macros. In that case you should probably declare the scratch registers you use. Some of the resulting patch looks gnarly and complex, but that's just the way that the existing code is structured, I'm just documenting it. The code itself probably could be rewritten to make things simpler and cleaner, but not as part of this patch. Webrev at http://cr.openjdk.java.net/~aph/scratch-regs/webrev/ I'm thinking of disabling register ownership checking in release builds and release branches because I don't want assertions to trigger in production systems and cause the VM to abort. We should leave it on in debug builds and the development trunk. Finally, I'm not wedded to the current syntax for declarations: I can think of some nicer ways to do it so that you could say use_scratch(rscratch1); rather than ScratchRegister rscratch1(__ as(), r8); Comments gratefully received. -- 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

3 10

RFR: AArch64: JDK-8232046: AArch64 build failure after JDK-8225681
by Andrew Dinn 06 Nov '19

06 Nov '19

Could I please have a review of the following patch AArch64-only which fixes a build failure on AArch64 introduced by JDK-8225681: JIRA: https://bugs.openjdk.java.net/browse/JDK-8232046 webrev: http://cr.openjdk.java.net/~adinn/8232046/webrev.00/ Testing: AArch64 build completes! tier1 tests pass (modulo a few clearly unrelated errors) vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java passes (that's the one JDK-8225681 was meant to fix) 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

[8u] 8231366: Shenandoah: Shenandoah String Dedup thread is not properly initialized
by Zhengyu Gu 04 Nov '19

04 Nov '19

This bug seems to exist since day one of 8u backport. The ConcurrentGCThread API is different in 8u and we leave ShenandoahDedupThread not properly initialized before it enters work loop. In Shenandoah String Deduplication tests, the bug results assertion failure that shows Thread::current() == NULL. The bug only manifests on Windows, is due to discrepancy of java_start() implementation on different OSs. e.g. it sets *thread* on Linux. Bug: https://bugs.openjdk.java.net/browse/JDK-8231366 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8231366/webrev.00/ Test: hotspot_gc_shenandoah on Windows and Linux. Thanks, -Zhengyu

4 6

RFR 8232992: Shenandoah: Implement self-fixing interpreter LRB
by Andrew Haley 31 Oct '19

31 Oct '19

On 10/25/19 3:29 PM, Zhengyu Gu wrote: > Test: > hotspot_gc_shenandoah (fastdebug and release) > x86_64 and x86_32 on Linux > aarch64 Linux > Windows x86_64 I didn't see this because I don't read all the Shenandoah and GC messages. The AArch64 code is unidiomatic and cumbersome in places, not to mention extremely confusing, and I can help with that. 236 void ShenandoahBarrierSetAssembler::load_reference_barrier_not_null(MacroAssembler* masm, Register dst, Address load_addr) { 237 assert(ShenandoahLoadRefBarrier, "Should be enabled"); 238 assert(dst != rscratch2, "need rscratch2"); 239 assert_different_registers(load_addr.base(), load_addr.index(), rscratch1); 240 assert_different_registers(load_addr.base(), load_addr.index(), rscratch2); 241 242 Label done; 243 __ enter(); 244 Address gc_state(rthread, in_bytes(ShenandoahThreadLocalData::gc_state_offset())); 245 __ ldrb(rscratch2, gc_state); 246 247 // Check for heap stability 248 __ tbz(rscratch2, ShenandoahHeap::HAS_FORWARDED_BITPOS, done); 249 250 // use r1 for load address 251 Register result_dst = dst; 252 if (dst == r1) { 253 __ mov(rscratch1, dst); This is pointless. On AArch64 mov(Rn, Rm) generates no code if Rn == Rm. 254 dst = rscratch1; 255 } 256 257 RegSet to_save_r1 = RegSet::of(r1); 258 // If outgoing register is r1, we can clobber it 259 if (result_dst != r1) { 260 __ push(to_save_r1, sp); 261 } On AArch64 registers are always saved in pairs, so it makes sense to push individual registers. You might as well push both if either is to be saved. 262 __ lea(r1, load_addr); 263 264 RegSet to_save_r0 = RegSet::of(r0); 265 if (dst != r0) { 266 __ push(to_save_r0, sp); 267 __ mov(r0, dst); 268 } 269 270 __ far_call(RuntimeAddress(CAST_FROM_FN_PTR(address, ShenandoahBarrierSetAssembler::shenandoah_lrb()))); 271 272 if (result_dst != r0) { 273 __ mov(result_dst, r0); 274 } 275 276 if (dst != r0) { 277 __ pop(to_save_r0, sp); 278 } 279 280 if (result_dst != r1) { 281 __ pop(to_save_r1, sp); 282 } 283 284 __ bind(done); 285 __ leave(); 286 } So, you want to save r1 and r0, but if either of those is the destination you don't want to save it. The code at ShenandoahBarrierSetAssembler::shenandoah_lrb() preserves everything but r1 and r0. I believe this is what you want: void ShenandoahBarrierSetAssembler::load_reference_barrier_not_null(MacroAssembler* masm, Register dst, Address load_addr) { assert(ShenandoahLoadRefBarrier, "Should be enabled"); assert(dst != rscratch2, "need rscratch2"); assert_different_registers(load_addr.base(), load_addr.index(), rscratch1, rscratch2); Label done; __ enter(); Address gc_state(rthread, in_bytes(ShenandoahThreadLocalData::gc_state_offset())); __ ldrb(rscratch2, gc_state); // Check for heap stability __ tbz(rscratch2, ShenandoahHeap::HAS_FORWARDED_BITPOS, done); // use r1 for load address Register result_dst = dst; if (dst == r1) { __ mov(rscratch1, dst); dst = rscratch1; } RegSet to_save = RegSet::of(r0, r1) - result_dst; __ push(to_save, sp); __ lea(r1, load_addr); __ mov(r0, dst); __ far_call(RuntimeAddress(CAST_FROM_FN_PTR(address, ShenandoahBarrierSetAssembler::shenandoah_lrb()))); __ mov(result_dst, r0); __ pop(to_save, sp); __ bind(done); __ leave(); } Please forward any patches which contain AArch64 assembly code to the aarch64-port-dev(a)openjdk.java.net list. I don't mean any criticism of you personally, but the AArch64 code in the Shenandoah GC barriers is gnarly and some of the most difficult to read in the whole port, probably because its authors, while undoubtedly brilliant, were not experienced AArch64 programmers. Let me help. :-) -- 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

Re: [aarch64-port-dev ] RFR 8232992: Shenandoah: Implement self-fixing interpreter LRB
by Andrew Haley 31 Oct '19

31 Oct '19

On 10/25/19 3:29 PM, Zhengyu Gu wrote: > Test: > hotspot_gc_shenandoah (fastdebug and release) > x86_64 and x86_32 on Linux > aarch64 Linux > Windows x86_64 I didn't see this because I don't read all the Shenandoah and GC messages. The AArch64 code is unidiomatic and cumbersome in places, not to mention extremely confusing, and I can help with that. 236 void ShenandoahBarrierSetAssembler::load_reference_barrier_not_null(MacroAssembler* masm, Register dst, Address load_addr) { 237 assert(ShenandoahLoadRefBarrier, "Should be enabled"); 238 assert(dst != rscratch2, "need rscratch2"); 239 assert_different_registers(load_addr.base(), load_addr.index(), rscratch1); 240 assert_different_registers(load_addr.base(), load_addr.index(), rscratch2); 241 242 Label done; 243 __ enter(); 244 Address gc_state(rthread, in_bytes(ShenandoahThreadLocalData::gc_state_offset())); 245 __ ldrb(rscratch2, gc_state); 246 247 // Check for heap stability 248 __ tbz(rscratch2, ShenandoahHeap::HAS_FORWARDED_BITPOS, done); 249 250 // use r1 for load address 251 Register result_dst = dst; 252 if (dst == r1) { 253 __ mov(rscratch1, dst); This is pointless. On AArch64 mov(Rn, Rm) generates no code if Rn == Rm. 254 dst = rscratch1; 255 } 256 257 RegSet to_save_r1 = RegSet::of(r1); 258 // If outgoing register is r1, we can clobber it 259 if (result_dst != r1) { 260 __ push(to_save_r1, sp); 261 } On AArch64 registers are always saved in pairs, so it makes sense to push individual registers. You might as well push both if either is to be saved. 262 __ lea(r1, load_addr); 263 264 RegSet to_save_r0 = RegSet::of(r0); 265 if (dst != r0) { 266 __ push(to_save_r0, sp); 267 __ mov(r0, dst); 268 } 269 270 __ far_call(RuntimeAddress(CAST_FROM_FN_PTR(address, ShenandoahBarrierSetAssembler::shenandoah_lrb()))); 271 272 if (result_dst != r0) { 273 __ mov(result_dst, r0); 274 } 275 276 if (dst != r0) { 277 __ pop(to_save_r0, sp); 278 } 279 280 if (result_dst != r1) { 281 __ pop(to_save_r1, sp); 282 } 283 284 __ bind(done); 285 __ leave(); 286 } So, you want to save r1 and r0, but if either of those is the destination you don't want to save it. The code at ShenandoahBarrierSetAssembler::shenandoah_lrb() preserves everything but r1 and r0. I believe this is what you want: void ShenandoahBarrierSetAssembler::load_reference_barrier_not_null(MacroAssembler* masm, Register dst, Address load_addr) { assert(ShenandoahLoadRefBarrier, "Should be enabled"); assert(dst != rscratch2, "need rscratch2"); assert_different_registers(load_addr.base(), load_addr.index(), rscratch1, rscratch2); Label done; __ enter(); Address gc_state(rthread, in_bytes(ShenandoahThreadLocalData::gc_state_offset())); __ ldrb(rscratch2, gc_state); // Check for heap stability __ tbz(rscratch2, ShenandoahHeap::HAS_FORWARDED_BITPOS, done); // use r1 for load address Register result_dst = dst; if (dst == r1) { __ mov(rscratch1, dst); dst = rscratch1; } RegSet to_save = RegSet::of(r0, r1) - result_dst; __ push(to_save, sp); __ lea(r1, load_addr); __ mov(r0, dst); __ far_call(RuntimeAddress(CAST_FROM_FN_PTR(address, ShenandoahBarrierSetAssembler::shenandoah_lrb()))); __ mov(result_dst, r0); __ pop(to_save, sp); __ bind(done); __ leave(); } Please forward any patches which contain AArch64 assembly code to the aarch64-port-dev(a)openjdk.java.net list. I don't mean any criticism of you personally, but the AArch64 code in the Shenandoah GC barriers is gnarly and some of the most difficult to read in the whole port, probably because its authors, while undoubtedly brilliant, were not experienced AArch64 programmers. Let me help. :-) -- 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

1 0

hg: aarch64-port/jdk8u-shenandoah/hotspot: 8209835: Aarch64: elide barriers on all volatile operations
by felix.yang＠huawei.com 31 Oct '19

31 Oct '19

Changeset: 02145a45eff6 Author: roland Date: 2018-11-05 12:53 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/02145… 8209835: Aarch64: elide barriers on all volatile operations Reviewed-by: aph, adinn ! src/cpu/aarch64/vm/aarch64.ad

1 0