RFR: 8253284: Zero OrderAccess barrier mappings are incorrect [v2]
Andrew Haley
aph at redhat.com
Fri Sep 18 08:27:14 UTC 2020
On 18/09/2020 06:03, Aleksey Shipilev wrote:
> On Fri, 18 Sep 2020 01:51:19 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:
>> Is the #if defined(ARM) referring to ARM in general here, or just
>> 32-bit ARM? Because there appears to be no change to its
>> definition, just rearrangement.
>
> No, there is `ARM` (32) and then there is `AARCH64` (64). This is
> why AArch64 fails: it effectively uses compiler barriers only
> through the confusing application of #else branches.
>
>> The patch is quite hard to follow, and made even more difficult by
>> multiple versions being attached to this PR.
>
> These are not multiple versions, those commits would be squashed
> into one on push -- that is how Skara workflow works. Look at the
> final version, which basically enables default (implicitly used by
> `ALPHA` and `AARCH64`) strong barriers -- that is the bug fix. It
> also keeps the light-weight barrier light for `X86` by calling it
> out explicitly.
It looks good enough to me.
--
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
More information about the hotspot-runtime-dev
mailing list