ShenandoahOptimizeFinals is an illegal optimization

[Aleksey Shipilev]

On 10/18/2017 03:35 PM, Roland Westrelin wrote:
> 
>> I think the failure mechanisms are different, but the phenomenon is the same: whether you can trust
>> final field values, and thus get exposed to "old" values -- which is formally allowed by spec. The
>> way you trust those fields, either via compiler optimizations that constant-fold "old" values, or
>> GC-specific optimization that exposes "old" values to users is not very relevant here, I think.
> 
> What you're saying is that code like:
> 
>     private final List<Provider> userList = new AbstractList<Provider>() {
>         public int size() {
>             return configs.length;
>         }
>         public Provider get(int index) {
>             return getProvider(index);
>         }
>     };
> 
> that initializes a field with a just allocated instance of an inner
> class is inherently broken?

Yup, seems that way to me. Using userList instance that calls into the prematurely published (by
construction) parent object is broken -- the final fields have no guarantees here. It fact, AFAIU,
their finality throw you under the bus even *if* userList instance was properly published, or you
are in the single thread, etc. I need to make some formal derivations to prove it, though.

I don't think we are arguing that ShOptimizeFinals should not be disabled. I think we discuss how
deep that disabling should go. In my mind, the optimization is still legal, so we need to turn it
off to ensure compatibility, but not really rip it out.

-Aleksey