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

[Doug Lea]

On 11/20/2016 06:36 PM, Hans Boehm wrote:
> On Wed, Nov 16, 2016 at 4:56 AM, Doug Lea <dl at cs.oswego.edu
> <mailto:dl at cs.oswego.edu>> wrote:
>
>     On 11/15/2016 01:44 PM, Hans Boehm wrote:
>
>         Generalizing final field memory ordering to non-final fields
>         also has
>         optimization consequences on the reader side that we're still
>         struggling
>         with for C++.
>
>         For example, on any flavor of ARM or Power, in
>
>         tmp = x;
>         ...
>         tmp2 = y;
>         if (tmp == tmp2) {
>             tmp3 = tmp2.a;
>         }
>
>         the last assignment can no longer be replaced by tmp3 = tmp.a,
>         because that
>         wouldn't preserve ordering between the load of y and that of a.
>         (I suspect
>         that such a replacement can be beneficial if the branch can be
>         correctly
>         predicted, since tmp may be available earlier.)
>
>         Presumably similar rules already apply to final field optimization.
>
>
>     If Tmp.a is final, both the tmp and tmp2 reads are possible only
>     after tmp.a is (finally) set, so the optimization is OK.
>     (This requires that there be no address speculation for "new" objects.
>     Otherwise all sorts of Java security properties would be broken.)
>
> Is that correct?

I think so, modulo the usual "we can't guarantee miracles" disclaimers...

>
> Consider the case in which x is written before the constructor setting a
> finishes, i.e. before the freeze action/fence, and y is set after the
> constructor finishes.

Meaning that the constructor published this as x before returning.

>   But it looks to me like 17.5.1 says that the
> read of a should see the initialized value, though I'm not positive
> about my reading.  And I have a vague recollection that Jeremy's
> original proposal may have allowed the read of a to see zero at this point?
>

In any case, I'm not sure we can/should decode JSR133 specs that we
know need fixing. For now, it seems that the most useful guarantee we
can make is the operational spec that any class with a final field
contains a storeStoreFence before/upon constructor return. As with
other VarHandle documentation, this is sometimes not enough, but the
best we have at the moment.

-Doug