[aarch64-port-dev ] Question about JVM option "-XX:+UseBarriersForVolatile" usage in aarch64.

[Andrew Haley]

On 4/2/20 2:22 PM, Andrew Dinn wrote:
> On 02/04/2020 02:48, Nick Gasson wrote:
>> I suggest if Derek can confirm that bug never made it into a production
>> part then we should completely remove UseBarriersForVolatile. Maybe with
>> a warning at startup if we detect that CPU variant. It adds a lot of
>> complexity to the volatile implementation for no clear benefit.
>
> One reason for having this switch was to provide a comparator for our
> scheme to implement the Java volatile accesses using ldar/stlr. That
> translation scheme avoids a dmb after the stlr allowing the value being
> written to be committed lazily while still providing the critical
> guarantee that prior writes are committed before it gets committed. The
> switch ensures we can fall back to a 'reference' implementation based on
> dmbs that, amongst other things, enforces immediate commit of the
> volatile write after commit of its predecessors.
>
> By removing support we lose the ability to test cases where
> synchronization errors occur with our scheme by switching to the
> 'standard' model.

Right, so I guess you're saying that we should keep it because there
may be bugs in our ldar/stlr code. I can think of no other reason.

> That may still be useful for finding bugs (current or newly
> injected) in our translation and, indeed, in new HW. Andrew Haley
> was not suggesting removing this option. He simply talked about
> making it a diagnostic option. I think that might be a wiser choice.

I'm fairly sure I said perhaps we could nuke it. I am strongly of the
opinion that rarely-used code behind runtime switches tends to rot, and
that any rotten part of the ship tends to spread.

-- 
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