Graal final field treatment with respect to optimizations

[Christian Wimmer]

On 04/27/2015 11:35 AM, Tom Rodriguez wrote:
>
>> On Apr 27, 2015, at 11:02 AM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>>
>> 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.
>
> I agree field profiling doesn’t seem like it’s the solution you’re talking about here.
>
> Years ago I build something like this for HotSpot that did a local symbolic analysis of all field initializations for a class to detect things like your example.  At the byte code level you can identify fields which are only stored in the constructor and capture symbolic properties of those initializations.  You don’t really need to care about final either, just that the amount of code you need to analyze is restricted through the use of access controls. You can dynamically trap all stores except the ones you’ve analyzying to treat fields as effectively final. In your example the fact that _arr is exactly Object[] is more interesting than having a constant length since store checks aren’t required for Object[].
>
> My experience was that it did some really clever things but that it largely didn’t translate into performance since you’re just shaving a tiny bits of work off something which is generally well optimized in the first place.  Type profiling and other speculative optimizations often pick up the interesting things here and maybe that’s what John was getting at with suggesting field profiling.

I did a similar thing on Graal a year or so ago, and the result was the 
same: It did not show any speedups.

The good news is that it was quite simple to implement in Graal, with 
just a little code in the interpreter that invalidates a Java-level 
assumption when a field is written.

-Christian