RFR(S): 8007144: Incremental inlining mistakes some call sites for dead ones and doesn't inline them
Roland Westrelin
roland.westrelin at oracle.com
Thu Jan 31 02:49:34 PST 2013
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.
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.
Roland.
More information about the hotspot-compiler-dev
mailing list