Odd interaction between ArrayList$Itr and Escape Analysis

[John Rose]

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.

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/4ac92e2f/attachment.html>