On Thu, 28 Oct 2021 07:23:52 GMT, David Holmes <dhol...@openjdk.org> wrote:
>> Something should happen when intrinsic is disabled. Other fences have native >> `Unsafe_{Load|Store|Full}Fence` entry points for this. We can, technically, >> do the same here, but I see no need. Instead, we can fall back to the >> already implemented stronger intrinsic. > > Thanks for clarifying. Now we have all the intrinsics in place we have the > choice of delegating either at the Java level or the native level, where > previously we had to delegate at the Java level to get the benefit of the > storeFence intrinsic. But it is fine as-is. Now I am actually thinking to drop `Unsafe_{Load|Store}Fence` entry points and delegate `Unsafe.{load|store}Fence()` to `Unsafe.fullFence()` as the fallback, in a similar way. It looks to me calling all the way to `unsafe.cpp` for a single barrier is not that useful. That's something for a separate PR. So it would be something like: - `storeStore` intrinsifies efficiently, or falls back to `release` - `loadLoad` always falls back to `acquire` (seems to be little sense to intrinsify this, as all platforms alias it to `acquire`) - `acquire` intrinsifies efficiently, or falls back to `full` - `release` intrinsifies efficiently, or falls back to `full` - `full` intrinsifies efficiently, or falls back to `Unsafe_FullFence`, which calls `OrderAccess::fullFence()`. ------------- PR: https://git.openjdk.java.net/jdk/pull/6136