More on memory barriers

[Doug Lea]

On 09/15/2014 11: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 is that storeStore was not distinguished from
release only because it did not impact any existing platforms. (Plus
as I mentioned before, storeStore is unlikely to ever be exposed
as part of any user-visible mode). But I can't see any reason not
to define a Op_MemBarStoreStore as a subtype of Op_MemBarRelease,
keeping everything the same in c2, but matching it more cheaply
on platforms where it matters. (You lose almost nothing, or maybe
exactly nothing treating it as release wrt other c2 internals.)

[Insert my usual disclaimers about not being a hotspot engineer.]

-Doug