RFR(L): 8005071: Incremental inlining for JSR 292

[Vladimir Kozlov]

Roland my main concern is GraphKit::kill_dead_call_outputs(). We 
avoiding such dead node elimination during paring since a graph may not 
complete and dominate information is not accurate. Can you bailout the 
round of later inlining if you detect such case and let 
PhaseRemoveUseless do cleanup for you?

The same about Compile::look_for_dead_calls(). Why you need this check 
if you do PhaseRemoveUseless?

Thanks,
Vladimir

On 12/14/12 7:13 AM, Roland Westrelin wrote:
> http://cr.openjdk.java.net/~roland/8005071/webrev.00/
>
> Current inlining heuristics are driven by the number of created nodes which is unrelated to the number of live nodes especially after optimizations are applied. C2 should perform inlining in a loop:
>
> while (more_inlining_candidates) {
>      apply_optimizations();
>      if (number_of_live_nodes > some_number) break;
>      inline_more();
> }
>
> In this change, C2 starts inlining at parse-time as usual until the existing heuristics kick in and prevent any further inlining. It then starts enqueuing candidates for further inlining. The candidates are restricted to the methods marked with the ForceInline annotation for now. It then enters the loop above. The optimizations applied are restricted to an igvn and a simple pass of loop clean up for now.
>
> Roland.
>