More on memory barriers

[David Holmes]

Hi Andrew,

On 16/09/2014 1: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?

My understanding of this is that, where the cookbook defines the 
barriers needed between given pairs of accesses, the hotspot JITs don't 
look at things at that level but just look at the volatile access in 
isolation. So a volatile read and a volatile write are surrounded by 
whatever pre- and post-barriers are needed in the worst-case. It's 
possible that C2 also has provision to later remove redundant barriers 
when examining a larger sequence of generated code, but I'm not familiar 
with those aspects of C2.

David

> Thanks,
> Andrew.
>