More on memory barriers
Andrew Haley
aph at redhat.com
Mon Sep 15 15:20:59 UTC 2014
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.
More information about the hotspot-dev
mailing list