<div dir="ltr"><div dir="ltr">Hi Kim,</div><div dir="ltr"><br>The implementation of the main JDK-8261027 change doesn't just try to provide the functionality when built with older GCC (or not GCC). What it does is dynamically switch to a more advanced implementation if the appropriate hardware capabilities were detected during the VM start. The selected code is picked by the compiler. So there are 2 implementations and non-LSE one is the default.  This allows us to provide a single binary for all supported ARM devices and get better performance where possible.</div><div dir="ltr"><br>From another hand, a less advanced implementation is always used initially in the default configuration. As you noticed, JDK-8282322 just makes it possible to create a build that uses the LSE variant from the start.<br></div><div dir="ltr"><br></div><div>-Dmitry</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 7, 2022 at 7:41 AM Kim Barrett <<a href="mailto:kim.barrett@oracle.com">kim.barrett@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I’m puzzled by this change:<br>
<br>
<a href="https://bugs.openjdk.org/browse/JDK-8282322" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8282322</a><br>
8282322: AArch64: Provide a means to eliminate all STREX family of instructions<br>
(2022-07-08, jdk20, no backports)<br>
<br>
It’s a followup to these changes:<br>
<br>
<a href="https://bugs.openjdk.org/browse/JDK-8261027" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8261027</a><br>
8261027: AArch64: Support for LSE atomics C++ HotSpot code<br>
(2021-02-12, jdk17, backported to jdk11, but not jdk8)<br>
<br>
8261649: AArch64: Optimize LSE atomics in C++ code<br>
(2021-02-19, jdk17, backported to jdk11, but not jdk8)<br>
<br>
[Also related is this<br>
<a href="https://bugs.openjdk.org/browse/JDK-8261660" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8261660</a><br>
AArch64: Race condition in stub code generation for LSE Atomics<br>
(2021-02-12, jdk17, superseded by 8261649)]<br>
<br>
which are essentially reimplementing gcc’s -moutline-atomics option. The point<br>
of doing this is to allow those changes to be used while building jdk with gcc<br>
versions that don't support -moutline-atomics, esp. for purposes of backports.<br>
(That option arrived with gcc8.5/gcc9.4/gcc10, enabled by default in gcc10. I<br>
guess some non-Oracle folks might still be using something earlier, esp. in<br>
the jdk17 timeframe when LSE support was being added.)<br>
<br>
8282322 builds on the earlier two, adding more complexity. It's purpose is to<br>
support a development activity (the use of rr for debugging), and requires<br>
building the jdk with additional configure options (specifying an `-march=` or<br>
`-mcpu` option that supports LSE, so the result of the build will *only* run<br>
on such hardware).  As noted in its review, it doesn't fit the normal criteria<br>
for backporting.<br>
<br>
For jdk20+ (where 8282322 landed), I question whether the approach being taken<br>
here really makes sense. If one is willing to assume a relatively recent<br>
version of gcc is being used, then I think there is no reason to reimplement<br>
the effect of -moutline-atomics. We could undo all three of those changes,<br>
reverting back to using gcc __atomic intrinsics, and rely on -moutline-atomics<br>
(explicitly requested for gcc8/9). In that case, nothing like 8282322 is<br>
needed; just specify armv8.1-a or later when configuring the build (which is<br>
already needed to activate the current 8282322 behavior) and LSE will be used,<br>
regardless of -moutline-atomics (or if it is even supported, if you want to<br>
use rr with an old gcc version).<br>
<br>
That would be a lot simpler.  It also makes it easier to make further changes.<br>
<br>
(Reading through the PR comments for 8282322, it looks like Andrew Haley<br>
almost suggested doing this. But instead of really buying into it, he seemed<br>
to be suggesting having a parallel implementation and some mechanism for<br>
selecting which one to use. That's definitely not what I'm suggesting.)<br>
<br>
In particular, I noticed all this because I'm working on 8293117: “Add atomic<br>
bitset functions”, and I’m trying to figure out how I should implement them<br>
for linux-aarch64. I’d rather not jump through the existing hoops when it<br>
would be really easy to just use the appropriate gcc __atomic intrinsics, as<br>
we used to do for other operations.<br>
<br>
The downside of going back to using the __atomic intrinsics rather than<br>
continuing to roll our own is that using an old gcc to build a recent jdk<br>
might get less than optimal performance on spiffy new hardware. I think that's<br>
worth the benefit of a much simpler implementation.<br>
<br>
</blockquote></div></div>