ShenandoahOptimizeFinals is an illegal optimization

[Christine Flood]

IThe safe thing in my mind is to just have ShenandoahOptimizeFinals always
default to false.

We don't want the appearance of incompatibility even if we are legally
within the letter of the law.


Christine

On Wed, Oct 18, 2017 at 9:21 AM, Aleksey Shipilev <shade at redhat.com> wrote:

> 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
>
>