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