ShenandoahOptimizeFinals is an illegal optimization

[Aleksey Shipilev]

On 10/18/2017 02:25 PM, Roland Westrelin wrote:
> If we have something like:
> 
> public class TestFinal {
>     final int field;
>     static TestFinal tf;
>     TestFinal() {
>         tf = this;
>         field = 0x42;
>     }
> 
>     public static void main(String[] args) {
>         new TestFinal();
>         // read tf.field
>     }
> }
> 
> the object can be evacuated while it is being constructed between the 2
> assignments. In that case tf points to from space with a value of zero
> for field "field". If tf.field is used later own, because field is
> final, with +ShenandoahOptimizeFinals, there will be no read barrier (in
> compiled code), so it will read 0 instead of 42.

Which is legal in Java, I think. The instance of TestFinal had leaked from the constructor, and
therefore no rule forbids seeing 0 in tf.field when read. This is similar to "Example 17.5.3-1.
Aggressive Optimization of final Fields" in JLS, e.g. the write happens "outside of" constructor as
far as the prematurely published instance of TF is concerned. Shenandoah optimization make that
allowed result visible.

I suspect something like this is happening in ProviderList...

> I'm working on a patch that disables ShenandoahOptimizeFinals for
> instance fields.

I think it makes sense to verify that -ShenandoahOptimizeFinals does not fail so that we have a
workaround, but as far as the optimization itself is concerned, I still believe it is legal.

Thanks,
-Aleksey