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

[Doug Lea]

On 11/15/2016 06:43 AM, Andrew Haley wrote:
> 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;

Note that the fence be placed any time after write of final field and
before return from constructor. In practice, all JVMs I know place a
fence immediately before return if any field is final, covering this
requirement in a simple way.  Including odd cases like programs that
assign a final field twice in a  constructor, which isn't illegal.
(Most people think it ought to be illegal, but too late for that.)

>
> 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

As Andrew mentioned, this discussion is not about analogs of
final fields, but instead about cases where fields can be (re)-written
by consumers. As Hans stated in the subsequent section of that
document (and agreed to by others in a few brief exchanges about this on 
this list in 2014), "In this case, it appears to be safe ...".
Which is not to say devoid of all possible surprises.
But it is surely sufficient with respect to the basic
security issues that are the primary motivation for
special rules for final fields.

[...omitted unrelated example...]

>
> 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.
>

If processors intrinsically performed a releaseFence whenever asked for
just a storeStoreFence, it might be defensible to simplify rules to
just say release here.  But this isn't so on ARM and possibly others.

-Doug