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

Reply via email to