On Thu, 28 Oct 2021 07:23:52 GMT, David Holmes <[email protected]> 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
