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

[Derek White]

[Sorry it took a long time to get some answers on this]

I think we should no longer enable UseBarriersForVolatile for the prototype ThunderX processors (model A1, variant 0). We believe that these should all have been replaced or decommissioned. We can add an error at startup if we detect that CPU.

Processor support is independent of whether UseBarriersForVolatile should be kept for debugging & development.

On that issue, in addition to the support being broken and not regularly tested, I think that this adds a veneer of complexity to already subtle code. Especially since about half of the uses of UseBarriersForVolatile are of the form "if not using extra barriers, add a barrier" ��. I'd be fine with seeing it go.

 - Derek White, Marvell


-----Original Message-----
From: aarch64-port-dev <aarch64-port-dev-bounces at openjdk.java.net> On Behalf Of Ningsheng Jian
Sent: Thursday, April 2, 2020 10:30 PM
To: Nick Gasson <nick.gasson at arm.com>; Andrew Dinn <adinn at redhat.com>
Cc: aarch64-port-dev at openjdk.java.net
Subject: [EXT] Re: [aarch64-port-dev ] Question about JVM option "-XX:+UseBarriersForVolatile" usage in aarch64.

External Email

----------------------------------------------------------------------
On 4/3/20 10:03 AM, Nick Gasson wrote:
> On 04/02/20 21:22 pm, Andrew Dinn wrote:
>> 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.
> 
> OK, but keeping it is not without cost. If UseBarriersForVolatile is 
> to have value as a reference implementation we need to expend effort 
> to test it and fix any bugs that arise from changes to other parts of 
> the code (see Xiaohong's original mail).
> 
> 

Yes, if the "reference" implementation is not widely used and tested, it might be buggy and misleading. I know that when Xiaohong was working on similar part on Graal [1], she spent a lot of time tracing the UseBarriersForVolatile issue in hotspot vm. So I agree with Nick and trend to not maintain this implementation.


[1] https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_oracle_graal_pull_2181&d=DwICaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=jMk_dCAeZJaapCXZaprROXyWC7AcLwFu-UIcW3SftNw&s=NXXKV871VjPzaiilChfrqlgm-viYGQBhujbES5aGNiw&e= 

Thanks,
Ningsheng