<div dir="ltr">Hello.<br><br>We've recently been looking into some JNI calls overhead on linux-aarch64, specifically in SharedRuntime::generate_native_wrapper(). It turned out that although the DMB ISH is not issued when UseSystemMemoryBarrier is on, the subsequent safepoint_poll is still made with acquire. It would be very beneficial (-25-75% JNI call overhead if there is no negative USMB impact) to avoid acquire there in case UseSystemMemoryBarrier is on, at least on some machines.<br><br>Looking at the history, there are few key points for this code. First, when Andrew Haley created the aarch64 implementation of Thread-local handshakes [0], Erik Österlund pointed to LDAR [1] and fence [3] necessity, and also described the logic behind that part at that time [2]. Robbin Ehn later added back barrier-less Java thread transitions [4], and the review mentions that store_load_barrier before load poll can be replaced with the compiler_barrier [5].<br><br>I wonder if it would be correct to emit the safepoint_poll with acquire=false in case UseSystemMemoryBarrier is true at least on some known CPUs. Regression tests don't reveal problems, but they don't produce eager safepoint/jni races.<br><br>-Dmitry<br><br>[0] <a href="https://bugs.openjdk.org/browse/JDK-8189596">https://bugs.openjdk.org/browse/JDK-8189596</a><br>[1] <a href="https://mail.openjdk.org/pipermail/hotspot-dev/2017-November/029264.html">https://mail.openjdk.org/pipermail/hotspot-dev/2017-November/029264.html</a><br>[2] <a href="https://mail.openjdk.org/pipermail/hotspot-dev/2017-November/029269.html">https://mail.openjdk.org/pipermail/hotspot-dev/2017-November/029269.html</a><br>[3] <a href="https://mail.openjdk.org/pipermail/hotspot-dev/2017-November/029277.html">https://mail.openjdk.org/pipermail/hotspot-dev/2017-November/029277.html</a><br>[4] <a href="https://bugs.openjdk.org/browse/JDK-8292591">https://bugs.openjdk.org/browse/JDK-8292591</a><br>[5] <a href="https://github.com/openjdk/jdk/pull/10123#issuecomment-1235123012">https://github.com/openjdk/jdk/pull/10123#issuecomment-1235123012</a><br></div>