RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions

Dmitry Chuyko dchuyko at openjdk.java.net
Thu May 19 10:08:40 UTC 2022


On Wed, 18 May 2022 19:05:03 GMT, Dmitry Chuyko <dchuyko at openjdk.org> wrote:

> On AArch64 it is sometimes convenient to have LSE atomics right from the start. Currently they are enabled after feature detection and RR reverse debugger works incorrectly.
> 
> New build configuration feature 'hardlse' is added. If it is enabled for aarch64 type of build, then statically compiled stubs replace the initial pessimistic implementation and dynamically generated replacements (when LSE support is detected). The feature works for builds of all debug levels.
> 
> New file atomic_linux_aarch64_lse.S is derived from atomic_linux_aarch64.S and inherits its copyright. This alternative static implementation corresponds to the dynamically generated code.
> 
> Note, this configuration part is necessary but not sufficient to fully avoid strex instructions for practical purposes. Other parts are:
> 
> * Run on the OS built without strex family instructions. E.g. Amazon Linux 2022.
> * Compile with outline atomics enabled and the configuration flag enabled. E.g. configure with
> --with-extra-cflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-cxxflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-ldflags='-Wl,--allow-multiple-definition' --with-jvm-features=hardlse
> 
> Testing: tier1, tier2 on linux-aarch64 release builds with feature off and feature on.

Thanks a lot for the great comments. Both suggestions make sense to me. The resulting code can be driven by the compiler flags in the configuration. 

As I see it:
1. To have a single compile time implementation based on __atomic_add_fetch intrinsics (no .S file at all).
2. In generated part wrap put 'if (UseLSE)' blocks under '#ifdef __ARM_FEATURE_ATOMICS'.

Some concerns:
1. It should work at least for Clang and GCC but still will require checking all os-cpu/compiler variants.
2. Windows-aarch64 is the most worrisome.
3. The way of configuration is different for different compilers, not a problem though if we need an optimized build or to make rr work.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8779



More information about the build-dev mailing list