RFC: linux-aarch64 and LSE support

[Dmitry Chuyko]

Yes, that looks like a cleaner approach. JDK-8282322 implementation just
focused on keeping the patch simple. There are no concerns about really old
GCCs. it simply would be nice to have a way to apply the change(s) to 17
which is buildable with recent enough versions.

On Thu, Sep 8, 2022 at 7:35 AM Kim Barrett <kim.barrett at oracle.com> wrote:

> On Sep 7, 2022, at 5:30 AM, Dmitry Chuyko <dmitry.chuyko at bell-sw.com>
> wrote:
> >
> > Hi Kim,
> >
> > 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.
>
> That's close to what the __atomic intrinsics with -moutline-atomics do.
> Except
> the compiler intrinsic approach has various benefits accrued from being
> built
> into the compiler.  (And the code that we need to maintain is much
> simpler.)
>
> > 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.
>
> JDK-8282322 requires an appropriate -march or similar option. The intrinsic
> approach gets the same desired effect (use only LSE) when such an option is
> provided, but inline.  That's one of the benefits.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20220909/cbfee67f/attachment-0001.htm>