RFR: 8291893: riscv: remove fence.i used in user space

[Fei Yang]

On Fri, 5 Aug 2022 09:37:54 GMT, Yadong Wang <yadongwang at openjdk.org> wrote:

> 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.
> 
> Tier1 of hotspot and jdk passed on unmatched.

The changes looks reasonable to me.
But looks like the data fence suggested before __builtin___clear_cache in icache_flush is missing?
As discussed on the list, we need to explicitly add this data fence to be safe since it is not specified by the riscv_flush_icache syscall issued from __builtin___clear_cache.

-------------

PR: https://git.openjdk.org/jdk/pull/9770