On Wed, 18 May 2022 19:05:03 GMT, Dmitry Chuyko <dchu...@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. This looks reasonable enough, but I take it that this would create an OpenJDK build that would not run on AArch64 systems without LSE instructions. Might it not be a better idea to build with outline-atomics, and use them in OpenJDK? That would also solve your problem, and we wouldn't have AArch64 Linux OpenJDK binaries which don't work on all systems. Note that atomic_bsd_aarch64.hpp already does this. I'm also concerned about code rot with options like this one. atomic_linux_aarch64_lse.S would not be tested in any standard configuration. ------------- PR: https://git.openjdk.java.net/jdk/pull/8779
