RFR: 8253284: Zero OrderAccess barrier mappings are incorrect [v2]
Andrew John Hughes
andrew at openjdk.java.net
Fri Sep 18 15:12:17 UTC 2020
On Fri, 18 Sep 2020 12:52:57 GMT, Andrew Haley <aph at openjdk.org> wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Fix copy-paste omission in bsd_zero
>
> Marked as reviewed by aph (Reviewer).
> > 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.
Ok, patch looks ok then. That seems to differ from the other architectures, where 'PPC' and 'X86' are referring to both
32- and 64-bit variants.
>
> > 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.
If there are not multiple versions, how is there a 'final version'? :-)
I eventually found the webrev with the full and final patch. One would normally rebase the patch with amendments, not
pile commit on commit and then leave it to a bot to rebase. I don't like the idea that the final commit will look
different to what is being reviewed.
-------------
PR: https://git.openjdk.java.net/jdk/pull/224
More information about the hotspot-runtime-dev
mailing list