ShenandoahOptimizeFinals is an illegal optimization

[Roman Kennke]

Am 18.10.2017 um 15:44 schrieb 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.
+1
and keep it always-on for static finals? or is that not safe? I mean, it 
*is* possible to mess with static finals using JNI/reflection too, right?

Can we run specjvm with and without that optimization to get a feeling 
what it does to performance?

Roman