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

[Andrew Dinn]

On 02/04/2020 14:22, 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. 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.
Correction he did actually raise the question as to whether to remove it
after recommending making it diagnostic. My vote for the latter still
stands.

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