Graal final field treatment with respect to optimizations

Vitaly Davidovich vitalyd at gmail.com
Mon Apr 27 20:29:10 UTC 2015


John,

Global/class-scope analysis is probably what I'm asking about - this
nomenclature is probably as good as any.

I think you guys are all saying that these types of optimizations kick in
with sufficient inlining automatically, and I agree.  But I think these
things all rely on latching onto a dominating check, which means the same
type of safety checks won't be performed multiple times.  I'm, however,
referring to cases where the 1st safety check is the only check - there's
nothing else subsequent to it that can piggyback and thus amortize the
cost.  Here's another example:

class Foo {
   final int[] arr1 = new int [3];
   final int[] arr2 = new int[4];
   final int[] arr3 = new int[5];

   long sum () {
     return arr1[0] + arr2[0] + arr3[0];
}
}

There's a range check on each one even though it's "obvious" there
shouldn't be one.  I'm sure we could come up with more examples, but the
common pattern is there's no dominator to use.

sent from my phone
On Apr 27, 2015 2:48 PM, "John Rose" <john.r.rose at oracle.com> wrote:

> On Apr 27, 2015, at 11:35 AM, Tom Rodriguez <tom.rodriguez at oracle.com>
> wrote:
>
>
> 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.
>
>
> Yep.  I think global (class-scope) analysis is what Vitaly is asking
> about, but as you point out (thanks!) local analysis after inlining gets
> nearly all of the good bits there.  The next technique that adds to local
> analysis is not global analysis but various profile-driven speculations.
> Global stuff is easy to think about but seems never to add much.
> Exception:  Whole-program static analysis sometimes has dramatic results.
> But most Java programs are hostile to whole-program stuff.
>
> — John
>


More information about the graal-dev mailing list