ShenandoahOptimizeFinals is an illegal optimization

[Roman Kennke]

It sounds reasonable to me. But we should leave it on for static final fields if it's not a problem there?

Roman

Am 18. Oktober 2017 15:21:22 MESZ schrieb Aleksey Shipilev <shade at redhat.com>:
>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

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.