[jmm-dev] The JSR-133 Cookbook and final fields

[Andrew Haley]

http://g.oswego.edu/dl/jmm/cookbook.html says:

... the special final-field rule requiring a StoreStore barrier in
      x.finalField = v; StoreStore; sharedRef = x;

but http://www.hboehm.info/c++mm/no_write_fences.html says:

... it is also generally unsafe to restrict the release ordering
   constraint in thread 1 to only stores. To see this, consider what
   happens if the initialization of x also reads x

I am convinced by Hans Boehm's argument in the second reference, and I
believe that only to use a StoreStore fence is too fragile unless you
disallow some optimizations.

Thread 1:

class X {
      int x;

      X() {
          a = 0;
          a++;
      }
}

void publish() {
    X x = new X();
}

Thread 2:

    x.a = 42;

This is safe enough at the Java level, but inlining of constructors at
the machine level mean that it's hard to guarantee without a LoadStore
at the end of the constructor.  On AArch64 at least we have address
dependency ordering from a load to a memory op based on it, which is
adequate in this case, I think.

I'd prefer to simply have an adjudication that we need a release
barrier at the end of a constructor, but mostly I'd like some sort of
decision.

Thanks,

Andrew.