[aarch64-port-dev ] RFR: [8u] 8209835: Aarch64: elide barriers on all volatile operations

[Andrew Dinn]

On 29/10/2019 10:04, Yangfei (Felix) wrote:
> Actually, I didn't see a real world problem related to this.  
> As you mentioned before, there should be a StoreLoad barrier between a volatile store and a volatile load.  
> I agree with that and I didn't see this kind of barrier when we have a getAndSet followed by a CompareAndSwap.  
> I just worried that developers may create code that relies on this memory model requirement.  

   . . .

>> Does this change make a significant performance improvement?
>>
>> It is not a low-risk change and I'm not sure it's worth it.
>> Andrew Dinn, what do you think?
Yes, it's a risk trade off.  Felix is right that there is a real risk
here. Programmers could legitimately write a program using a combination
of getAndSetXXX followed by a CompareAndSwapXXX,expect it to work as
advertised but run into problems because of the current implementation.
However, no one has done that yet (as far as we know). The question is
what is being traded off.

I am not sure the risk from the patch is very large. The code being
relied on to detect and apply the new rules is Roland's modified
predicates that detect the need for acquire/release semantics at a
load/store. They are aided and abetted in identifying the accompanying
leading and trailing membars by generic code; in other words they are
not relying on the old shape-related predicates that were always very
fragile.

Also, these predicates and the corresponding rule changes are in use
(and have baked) upstream in jdk11u+ to handle the proposed new
translations and are already in use (and have baked) in jdk8u to handle
the existing translations for volatile operations. So, I think the risk
of breakage from introducing the patch is low.

On the other hand the danger of sticking to the status is arguably
theoretical. On the face of it, it seems unlikely that code is going to
mix these two operations on the same object field. I am not sure I'd
like to be held to that though. Nor do I relish trying to work out that
this is the problem if someone does run into it (nor would that unlucky
someone be very happy, I suspect).

So, on balance I think it's probably worth pushing this change just in
case it does hit someone and we end up having to deal with the fallout.

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