Odd interaction between ArrayList$Itr and Escape Analysis

[Vitaly Davidovich]

On Wed, Sep 28, 2016 at 1:37 PM, John Rose <john.r.rose at oracle.com> wrote:

> On Sep 28, 2016, at 9:42 AM, Krystal Mok <rednaxelafx at gmail.com> wrote:
>
>
> I do also have another patch for the general case for "unused unloaded
> arguments". I haven't gotten around to polish and test that patch yet, but
> since we're seeing a good motivation on the OpenJDK side as well, I may as
> well go back and get that patch ready soon.
>
> A null guard is a good way to go. It's basically the same kind of logic
> that C2 OSR entry already uses. In this case, at a call site, a null guard
> on the caller-side against an argument whose type is unloaded is one way to
> do it.
>
>
> This is the fix I would prefer for the inliner.
>
> (There are of course other alternatives. e.g. If we focus on the
> callee-side, in a compiler with a mixed top-down / bottom-up inlining
> heuristics system, the (devirtualized if needed) callee can be inspected
> first to see if an argument of unloaded type is never used or not. If it is
> never used, don't even bother inserting the null guard on the caller-side,
> and just go ahead and inline would be good and safe. C2 doesn't have this
> luxury yet so tackling the problem with a caller-side solution is easier to
> do.)
>
>
> I'd like to do more in this direction.  The EA function summarizer could
> be overloaded to also gather data on the usage of arguments (as well as
> their escape status).  For example, if an argument is used to gate a branch
> (somehow), then having that argument be constant should "add points" to the
> heuristic that decides inlining.  *In general*, constant arguments should
> be an "argument" to raise the likelihood of inlining a call.
>
Yes! I'm a bit surprised we've gone so long without constants adding bonus
points for inlining.

I'm definitely seeing places where a callsite isn't inlined for one reason
or another, but there's a constant (sometimes several) being passed through
which would end up folding a bunch of code in the callee, and sometimes
eliminating code there altogether.

>
> I'm going to guess that this work would be better done in Graal, but we
> don't have that luxury yet.
>
> — John
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160928/352c5b9c/attachment.html>