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

[Doug Lea]

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

-Doug