ShenandoahOptimizeFinals is an illegal optimization
Roland Westrelin
rwestrel at redhat.com
Wed Oct 18 13:01:49 UTC 2017
> 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.
In a sequential program? Whichever way we read the spec, that doesn't
sound reasonable to me.
> 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.
It breaks existing code. You can't use inner classes and safely refer to
fields from the outer class anymore. It doesn't sound like we want to
leave this on.
Roland.
More information about the shenandoah-dev
mailing list