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