Request for review (S): 7022998: JSR 292 recursive method handle calls inline themselves infinitely
christian.thalinger at oracle.com
Thu Mar 17 04:25:12 PDT 2011
On Mar 15, 2011, at 7:41 PM, Vladimir Kozlov wrote:
> Christian Thalinger wrote:
>> On Mar 15, 2011, at 5:57 PM, Vladimir Kozlov wrote:
>>> 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.
CompileTask seems suitable. I put a couple of static methods in there and the code is much cleaner now. I updated the webrev.
>>> 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.
So I'd say we just drop the "---" and use "n" as the indicator for a native method wrapper.
>>> Main fix is fine.
>> -- Christian
>>> Christian Thalinger wrote:
>>>> 7022998: JSR 292 recursive method handle calls inline themselves infinitely
>>>> 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.
More information about the hotspot-compiler-dev