The usage of fence.i is in-efficient or redundant in the current implementation of riscv port now. The riscv port has already followed the [RISC-V platform specification](https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc): the write hart use the __builtin__clear_cache or the syscall riscv_flush_icache directly after modifying code in riscv port, to execute fence.i on local hart and other harts by IPI. That's because fence.i only synchronizes the local hart, and the OS can reschedule the user hart to a different physical hart after the fence.i.

"To order older stores before younger instruction fetches, user-level programs must use system supplied
library calls (e.g. GNU libc's __riscv_flush_icache, which invokes the Linux kernel's
corresponding vDSO routine), rather than executing the fence.i instruction directly."

What now seems unnecessary is that we also put fence.i in front of code that will be modifed concurrently, just like Aarch64 port. Because the icache flush syscall already provides the explicit icache synchronization between all harts, so that we can remove fence.i used in the read hart.
Details of the discussion can be found in https://mail.openjdk.org/pipermail/riscv-port-dev/2022-July/000571.html.

In contrast, the isb in aarch64 is not broadcast by the writing PE, so any other PE must perform its own isb synchronization after it knows that the instruction update is visible.