[9] RFR (S): 8059241: Incremental inlining is too hot when compiling Nashorn/Octane

[John Rose]

On Apr 29, 2015, at 11:11 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
> 
> Incremental inlining fails miserably when a call site dies while waiting for being inlined. It happens when previously inlined call causes some branches to be eliminated, but the info hasn't been propagated yet.
> 
> I tried to enhance dead code detection logic, but failed. So, I reverted the following part of original fix:
> "(1) Reduce PhaseRemoveUseless frequency: inline in larger chunks until IR size LiveNodeCountInliningCutoff, then eliminate dead nodes."

Oh, that's sad and annoying.

I have a couple of comments.

Since you are cleaning up the contract for inline_incrementally_one (a good idea), remove the cross-call role of the global inlining_progress flag, by having inline_incrementally_one return a boolean sample of inlining_progress, meaning "there is more work to be done".  Then the only reader of that flag will be inline_incrementally_one itself, and the only asserter (writer to true) of the flag will be the call generator.

Some complex optimizations can become buggy when the graph changes due to dead path elimination.  One way we can defend against this is to delay the removal of dead paths to a cleanup phase.  There are several ways to do this trick.  To maintain certain connectivity properties, we introduce not-really-conditional NeverBranch nodes, which are rewritten extremely late.  A "washable" version of NeverBranch nodes (which "washes out" sooner than the current ones) could perhaps be used to delay path-cutting.  More commonly, in loop opts, we use various kinds of opaque nodes to block constant folding when it would be inconvenient.  Perhaps during incremental inlining we could block path-cutting by introducing some kind of opaque data or control node, which would wash out in the PhaseIterGVN that you originally intended to run after several rounds of incremental inlining.

I'm not sure if this would be profitable in this case, but the idea of delaying path-cutting has been useful in the past.

— John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150429/83868dd5/attachment.html>