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

[Andrew Dinn]

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

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill