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

[Erik Osterlund]

Hi Xiaolin,

Note that the guard for nmethod entry barriers is used as data only.
Its address just happens to be in the code cache, but it is never executed.

Thanks,
/Erik

> -----Original Message-----
> From: hotspot-compiler-dev <hotspot-compiler-dev-
> retn at openjdk.java.net> On Behalf Of ???(??)
> Sent: Tuesday, 22 February 2022 04:29
> To: hotspot-compiler-dev <hotspot-compiler-dev at openjdk.java.net>
> Subject: 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/nati
> veInst_aarch64.hpp#L95-L101
> 2.
> https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/gc/s
> hared/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