More on memory barriers

[Dean Long]

If volatile store uses AArch64 "stlr" and volatile load uses "ldar", 
then is that enough
(no additional barriers, including StoreLoad, required)?  That's my 
understanding
from the comments in orderAccess.hpp regarding ia64 st.rel and ld.acq.

dl

On 9/15/2014 8:20 AM, Andrew Haley wrote:
> I'm still looking at the best way to generate code for AArch64 volatiles,
> and I've come across something really odd.
>
> void Parse::do_put_xxx(Node* obj, ciField* field, bool is_field) {
>    bool is_vol = field->is_volatile();
>    // If reference is volatile, prevent following memory ops from
>    // floating down past the volatile write.  Also prevents commoning
>    // another volatile read.
>    if (is_vol)  insert_mem_bar(Op_MemBarRelease);
>
> A release here is much too strong: the JSR-133 cookbook says that we
> only need a StoreStore here, presumably because we're going to emit a
> full StoreLoad barrier after the store to the volatile field.
>
> On a target where this makes an actual difference to code quality,
> this matters.  Does anyone here understand what this release fence is
> for?
>
> Thanks,
> Andrew.