Graal final field treatment with respect to optimizations

[Vitaly Davidovich]

Thanks Gilles.

Why is there a restriction that receiver has to be constant as well? In
addition, why does the value have to be *not* default? Specifically, an
example I mentioned to John was akin to this:

final class Foo {
     private final Object[] _arr = new Object[10];

     int capacity() { return _arr.length; }

     Object getFirst() { return _arr[0]; }
}

What's the reason capacity() cannot be constant folded to 10 if the
receiver is non-constant? Likewise with getFirst().  Is this again because
there's no field profiling? I suspect so, but just want to double check.

Has any thought been given to doing some (basic) field profiling? Actually,
I'm reluctant to call the above profiling since it seems like it could be
done at parse/compile time? To me profiling sounds more like "there's a
final field of interface type Foo, and we profile to see that at runtime we
only have 1 real type stored there, FooImpl", or something like that.

Thanks


On Mon, Apr 27, 2015 at 1:45 PM, Gilles Duboscq <gilwooden at gmail.com> wrote:

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