RFR(S): 8007144: Incremental inlining mistakes some call sites for dead ones and doesn't inline them

[Vladimir Kozlov]

Thank you, Roland, fro finding and fixing this.

On 1/31/13 2:49 AM, Roland Westrelin wrote:
> http://cr.openjdk.java.net/~roland/8007144/webrev.00/
>
> Before incremental inlining inlines a new call site, it sanity checks the input state of the call node: if the call is in a part of the graph that is dead, there's no need to proceed with inlining and, the parser doesn't expect a strange input state anyway. One of the check consists in testing the input edges to the call node (that correspond to input arguments to the call) for top. Long/double arguments to a call are in 2 halves, one of which is top so incremental inlining will skip all calls with at least a long or double argument, mistaken them for dead calls.

The fix look fine.

>
> This bug impacts the performance of the box2d test with nashorn.
>
> I also fixed some PrintInlining problems. The PrintInlining output would always report a call site candidate for incremental inlining as "inline (hot)" whether the call site was actually inlined or not which would result in duplicate lines most of the time (one "inline (hot)" and one "live nodes > LiveNodeCountInliningCutoff"). For an incremental inlining call site, I also changed the message to: "incremental inline (hot)". With this fixed there are still some inconsistencies with string calls that are most of the time reported as "inline (hot)" even though inlining is incremental.

Could you do this as separate fix since it is not complete? Adding 
needs_printing only to LateInlineString create more mess (why only for 
laterstring and not for incremental inlining?) which is difficult to 
follow. We need to think more how to clean up printing for late inlining.

And I am fine with next change in the fix:

-  C->print_inlining_insert(this);
+  if (PrintInlining) {
+    print_inlining_late("incremental inline (hot)");
+  }

Thanks,
Vladimir

>
> Roland.
>