Do `NativeInstruction::set_*_at()` and `BarrierSetNMethod::disarm()` miss icache invalidation operations on AArch64 platform?

[郑孝林(云矅)]

Hi experts on AArch64,

As the topic, I was wondering if these methods lack icache invalidation operations when patching data saved in a code region, though it seems not harmful.
1. https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/nativeInst_aarch64.hpp#L95-L101
2. https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/gc/shared/barrierSetNMethod_aarch64.cpp#L49-L51

When patching a trampoline address, we will go
```
NativeCall::set_destination_mt_safe()
  -> NativeCallTrampolineStub::set_destination()
    -> NativeInstruction::set_ptr_at()
```

bl(1) -> ldr
            br
            <int64: the real call target (2)>

When a call target is getting updated, (1) is flushed but (2) is not on AArch64. So I was wondering if there are more possibilities for other cores to see the new patching behavior with a theoretically longer latency when code is running at full speed on every core? Since when other cores observe (1), they are likely run without observing (2) in theory.

Also `BarrierSetNMethod::disarm()` will patch the guard address as well, without flushing the related icache address on AArch64. 

Maybe something like http://cr.openjdk.java.net/~xlinzheng/1.diff ?

Previously I wanted to send this to the aarch64-port-dev, but seems that list is not so active - I see only Duke's there syncing changesets.
I feel sorry in advance if this isn't worth a discussion, and am very glad to receive any input.

Thanks,Xiaolin