Request for review (S): 7022998: JSR 292 recursive method handle calls inline themselves infinitely

[Vladimir Kozlov]

Christian Thalinger wrote:
> On Mar 15, 2011, at 5:57 PM, Vladimir Kozlov wrote:
>> Christian,
>>
>> Instead of duplicating code in several places could you factor it in one method?
> 
> Actually I wanted to do that but I didn't know where to put the code.  sharedRuntime?

May be a static method in CompileTask or AbstractCompiler since it is 
compilation information.

> 
>> sharedRuntime.cpp: you removed "---" which was indication of native method wrapper compilation.
> 
> Is there a difference between the "n" printed in nmethod::print_compilation and the "n" printed in AdapterHandlerLibrary::create_native_wrapper?

I never saw nmethod::print_compilation using 'n' in output. But I assume it is 
the same.

Vladimir

> 
>> Main fix is fine.
> 
> Okay.
> 
> -- Christian
> 
>> Thanks,
>> Vladimir
>>
>> Christian Thalinger wrote:
>>> http://cr.openjdk.java.net/~twisti/7022998/
>>> 7022998: JSR 292 recursive method handle calls inline themselves infinitely
>>> Reviewed-by:
>>> Methods doing recursive method handle calls, like in JRuby's
>>> bench_fib_resursive.rb or bench_tak.rb, inline themselves infinitely.
>>> This results in a huge method which hits compile thresholds and aborts
>>> inlining resulting in poor performance.
>>> The inlining logic needs to know about method handle call sites and
>>> search the call stack for recursive calls.
>>> This change also cleans up the PrintCompilation, PrintInlining and
>>> TraceTypeProfile output to be aligned since the tiered compilation
>>> changes added some additional output.
>>> src/share/vm/c1/c1_GraphBuilder.cpp
>>> src/share/vm/opto/bytecodeInfo.cpp
>>> src/share/vm/opto/doCall.cpp
>>> src/share/vm/runtime/sharedRuntime.cpp
> 
>