RFR: 8276096: Simplify Unsafe.{load|store}Fence fallbacks by delegating to fullFence

[Aleksey Shipilev]

On Mon, 1 Nov 2021 02:15:04 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I'm not quite seeing the motivation here. Your claim is that the non-intrinsic implementations involve a native call and so that is too expensive; yet the new code still relies on the fullFence being intrinsified else it is still a native call and a heavier barrier. If these fences were intrinisified piecemeal then perhaps this is an issue on some platform, but is that really the case? If you intrinsified one wouldn't you intrinsify all?

Yes, that was not clear, sorry. For current platforms, it is mostly a maintenance cleanup to shrink the unnecessary Unsafe interfaces: if we disable the `acquireFence` intrinsic, we don't need to call into native fallback (which would be excessive), instead we can just go to Java-level fallback (which would also be faster). 

I am looking at the cases where we would like to only intrinsify `fullFence`, for example for Zero interpreter. Instead of handling all three flavors of fences, we can get the majority of performance win by only drilling the interpreter-entry-intrinsic hole for `fullFence`, and let everything else handled at Java level.

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

PR: https://git.openjdk.java.net/jdk/pull/6149