On Mon, 1 Nov 2021 02:15:04 GMT, David Holmes <[email protected]> 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
