Graal final field treatment with respect to optimizations

Gilles Duboscq gilwooden at gmail.com
Mon Apr 27 17:45:27 UTC 2015


Hi Vitaly,

We currently do not respect the TrustNonStaticFinalFields field.
We have a "@Stable-like" behaviour for non-static final fields:

* static final:
  We always constant fold

* final
  We constant fold if the receiver is constant and if the value is not
default (null, 0, 0.0, false...). This is not what HotSpot normally does
and we just enabled this to see what would happen. At some point we'll
probably change to only do that if TrustNonStaticFinalFields is true just
to respect HotSpot's wish though.

* @Stable final array[]
  We constant fold if the receiver is constant and if the value is not
default (null, 0, 0.0, false...) and we apply the @Stable final property
for the elements of the array (up to the declared field's dimension). i.e.
an access like array[0] would also be constant folded (this would not be
done for final: we would access a constant array object the the load from
this array would stay).

* Some fields are automatically promoted to @Stable
  The String.value field and synthetic $VALUES, ENUM$VALUES, $SwitchMap$
and $SWITCH_TABLE$ fields (from enums) are automatically promoted to
@Stable.

We do not do any additional profiling of fields in the runtime.



On Fri, Apr 24, 2015 at 3:57 PM Vitaly Davidovich <vitalyd at gmail.com> wrote:

> Hi guys,
>
> I recently had a thread on hotspot-compiler-dev where John Rose shed some
> light on what the TrustNonStaticFinalFields experimental flag implies in
> the C2 compiler:
>
> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-April/017739.html
>
> Based on that exchange, I see that there are some scenarios where some
> optimization opportunities are missed, specifically due to missing field
> profiling.  That got me thinking -- how does Graal handle this, and does it
> do something better here? Clearly Graal has to also be mindful of final
> fields being changed via reflection, but are there any speculative
> optimizations around trusting that final fields are mostly unchanged (or
> plans to do that)?
>
> Thanks
>


More information about the graal-dev mailing list