The Java Memory Model is a tradeoff between performance and reliability.
We do not promise sequential consistency, and will not do so, but
providing more guarantees that we do at present while preserving performance
is well worth considering.

For final fields, the JMM guarantees that another thread will never see the field
in its uninitialized state, even in the absence of a happens-before relationship.

Many programs make the stronger assumption that this is the case for any field
initialized in a constructor. It is certainly an easy "mistake" to make,
and it is difficult to fix without adding much stronger restrictions
(I'm thinking of making the field volatile).

The canonical example is a caching int field
in an otherwise immutable object initialized in a constructor to a -1
value and then lazily initialized when needed.
Even without synchronization, this is thread-safe, except that another
thread might see the field set to zero.

C2 currently inserts a StoreStore barrier at the end of a constructor
if it contains a final field. Since there is no actual code emitted
(on current JDK-targeted hardware)
and merely some reorderings are no longer permitted if the constructor
is inlined, it should be very cheap to do this.
We should run a performance experiment.

From email:

> I'm not sure, but I think the memory barrier in c2 ends up emitting no
> code on sparc and x86,

Right.

> but merely prevents further reordering
> if inlined, which would mean the cost is very low.

Always worth measuring to find out for sure though. Adding too many
reordering constraints can make the instruction scheduler unhappy
and in turn generate code that encounters a lot of memory stalls
(which would likely be most apparent on P4/xeons).

(Also: I don't think the escape-analysis stuff is smart enough
to suppress reordering constraints when objects are proven
thread-local. This probably needs attention, as does the lack
of smarts about reloading final fields across various barriers.)