RFC: linux-aarch64 and LSE support

[Andrew Haley]

On 9/7/22 05:41, Kim Barrett wrote:
> I’m puzzled by this change:
> 
> https://bugs.openjdk.org/browse/JDK-8282322
> 8282322: AArch64: Provide a means to eliminate all STREX family of instructions
> (2022-07-08, jdk20, no backports)
> 
> It’s a followup to these changes:
> 
> https://bugs.openjdk.org/browse/JDK-8261027
> 8261027: AArch64: Support for LSE atomics C++ HotSpot code
> (2021-02-12, jdk17, backported to jdk11, but not jdk8)
> 
> 8261649: AArch64: Optimize LSE atomics in C++ code
> (2021-02-19, jdk17, backported to jdk11, but not jdk8)
> 
> [Also related is this
> https://bugs.openjdk.org/browse/JDK-8261660
> AArch64: Race condition in stub code generation for LSE Atomics
> (2021-02-12, jdk17, superseded by 8261649)]
> 
> which are essentially reimplementing gcc’s -moutline-atomics option. The point
> of doing this is to allow those changes to be used while building jdk with gcc
> versions that don't support -moutline-atomics, esp. for purposes of backports.
> (That option arrived with gcc8.5/gcc9.4/gcc10, enabled by default in gcc10. I
> guess some non-Oracle folks might still be using something earlier, esp. in
> the jdk17 timeframe when LSE support was being added.)

Sure. The timing wasn't good: the outline-atomics patch went in to GCC
in September 2019, but was back-ported to GCC releases by May/June 2021.
Our patch was committed in Feb that year.

> For jdk20+ (where 8282322 landed), I question whether the approach being taken
> here really makes sense. If one is willing to assume a relatively recent
> version of gcc is being used, then I think there is no reason to reimplement
> the effect of -moutline-atomics. We could undo all three of those changes,
> reverting back to using gcc __atomic intrinsics, and rely on -moutline-atomics
> (explicitly requested for gcc8/9). In that case, nothing like 8282322 is
> needed; just specify armv8.1-a or later when configuring the build (which is
> already needed to activate the current 8282322 behavior) and LSE will be used,
> regardless of -moutline-atomics (or if it is even supported, if you want to
> use rr with an old gcc version).
> 
> That would be a lot simpler.  It also makes it easier to make further changes.
True. It all feels a bit early to me, though. I don't think that OpenJDK has ever
needed so recent compiler features before. We've always been very conservative
about what we depend on. So it might be OK to do this, but (to me) it feels
like sailing close to the wind.

I'm curious, though: wouldn't atomic bitset ops be based on CAS? If so, you don't
need to care how CAS is implemented.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671