ShenandoahOptimizeFinals is an illegal optimization

[Aleksey Shipilev]

On 10/18/2017 03:14 PM, Roland Westrelin wrote:
> 
>> Tough call. Seems like the same thing as with TrustFinalNonStaticFields -- probably we want to
>> condition ShenandoahOptimizeFinals on TrustFinalNonStaticFields? And, can we at trust @Stable fields
>> with this optimization?
> 
> I don't think this is the same as TrustFinalNonStaticFields. AFAIU,
> TrustFinalNonStaticFields exists because some fields are declared final
> but not final in practice (a field that can be updated once we have
> returned from the constructor by reflection or unsafe). The final fields
> involved here are really final.

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.

This kinda tells that we might "just" say:

 // Do not optimize final fields, if the rest of runtime does not
 // believe their old values too:
 if (!TrustFinalNonStaticFields) {
   FLAG_SET_DEFAULT(ShenandoahOptimizeFinals, false);
 }

-Aleksey