The ARMv8-A architecture employs a weakly ordered model of memory[1]. Some armv8 processors might reorder stores. We caught this issue when we run jcstress.  
eg. org.openjdk.jcstress.tests.defaultValues.arrays.small.plain.ByteTest

by putting ParallelGC and C1 together: 
java -XX:TieredStopAtLevel=1 -XX:CompileOnly=ByteTest::actor1 -XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -XX:+UseParallelGC  ByteTest

we observe OoBoundary Exception or Wrong answer for the test. 
java.lang.ArrayIndexOutOfBoundsException: 0
	at org.openjdk.jcstress.tests.defaultValues.arrays.small.plain.ByteTest.actor2(ByteTest.java:55)
	at org.openjdk.jcstress.tests.defaultValues.arrays.small.plain.ByteTest_jcstress.actor2(ByteTest_jcstress.java:193)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)

We believe the root cause is putfield happened before the completion of the bytecode newarray.  actor2 peeked an oop in wrong state.  
  public void actor1();
    Code:
       0: aload_0
       1: iconst_4
       2: newarray       byte
       4: putfield      #2                  // Field arr:[B
       7: return

G1 is tricky because g1 emits a membar(Assembler::StoreLoad) in its write_barrier_post.  The most obvious example comes from parallelGC as follows. 0x0000ffff893382fc-308 is the slowpath of allocate_array. please refer to LIR_Assembler::emit_alloc_array(c1_LIRAssembler_aarch64.cpp)

  0x0000ffff893382c8:   dmb ishst                       ;*newarray {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - ByteTest::actor1@2 (line 5)
  0x0000ffff893382cc:   lsr x8, x0, #3
  0x0000ffff893382d0:   str w8, [x1, #12]
  0x0000ffff893382d4:   lsr x0, x1, #9
  0x0000ffff893382d8:   mov x1, #0x3000                 // #12288
  0x0000ffff893382dc:   movk    x1, #0xa3b9, lsl #16
  0x0000ffff893382e0:   movk    x1, #0xffff, lsl #32
  0x0000ffff893382e4:   strb    wzr, [x0, x1, lsl #0]       ;*putfield arr {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - ByteTest::actor1@4 (line 5)
  0x0000ffff893382e8:   ldp x29, x30, [sp, #48]
  0x0000ffff893382ec:   add sp, sp, #0x40
  0x0000ffff893382f0:   ldr x8, [x28, #264]
  0x0000ffff893382f4:   ldr wzr, [x8]                   ;   {poll_return}
  0x0000ffff893382f8:   ret
  0x0000ffff893382fc:   adrp    x8, 0x0000ffff88901000      ;   {runtime_call new_type_array Runtime1 stub}
  0x0000ffff89338300:   add x8, x8, #0x300
  0x0000ffff89338304:   blr x8                          ; ImmutableOopMap {c_rarg1=Oop }
                                                            ;*newarray {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - ByteTest::actor1@2 (line 5)
  0x0000ffff89338308:   b   0x0000ffff893382cc

The jump at 0x0000ffff89338308 misses dmb ishst.  This is not the case for C2.

Reference: 
[1] https://developer.arm.com/docs/100941/0100/the-memory-model