RFR (XS): 8012941: JSR 292: too deep inlining might crash compiler because of stack overflow

[Christian Thalinger]

On Oct 14, 2013, at 11:42 AM, Christian Thalinger <christian.thalinger at oracle.com> wrote:

> Looks good.  It's unfortunate that we have to add yet another product flag for this.

We talked about this product flag during lunch and we shouldn't add it.  Can you make it a develop flag?

> 
> On Oct 14, 2013, at 11:38 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
> 
>> On 10/14/13 9:52 PM, Vladimir Kozlov wrote:
>>> Why C2 is not affected? Did it bailout inlining early?
>> 8012941 is about C1. But C2 is also affected - it fails to delay inlining of @ForceInline methods in some situations (regression test fails with C2). I want to address it separately, since the strategy of the fix should be different.
>> 
>>> 100 could be not enough but reasonable.
>> In that case the performance will be suboptimal. For C1 it is acceptable.
>> 
>>> I don't like changing inlining behavior for excluded methods. You need
>>> to do special case explicitly for CompileOnly. And do it as separate fix.
>> Ok. Will do.
>> Removed regression test for now. It takes too much time to run.
>> 
>> Updated webrev:
>> http://cr.openjdk.java.net/~vlivanov/8012941/webrev.01/
>> 
>> Best regards,
>> Vladimir Ivanov
>>> 
>>> thanks,
>>> Vladimir
>>> 
>>> On 10/14/13 10:13 AM, Vladimir Ivanov wrote:
>>>> http://cr.openjdk.java.net/~vlivanov/8012941/webrev.00/
>>>> 89 lines changed: 82 ins; 0 del; 7 mod
>>>> 
>>>> C1 inlining is implemented in a depth-first fashion as a recursion.
>>>> During compilation of lambda forms @ForceInline annotation is used
>>>> extensively to force inlining of generated methods. For a long chain of
>>>> method handles, inlining of methods marked w/ @ForceInline can overflow
>>>> a stack and crashes VM.
>>>> 
>>>> I chose a conservative way to fix the problem and set a limit on maximum
>>>> inlining depth for methods marked @ForceInline.
>>>> 
>>>> Having it set to 100:
>>>>  - no crash observed anymore w/ C1
>>>>  - no inline bailouts due to MaxForceInlineLevel reached on octane
>>>> benchmarks
>>>> 
>>>> For ordinary methods the limit(MaxInlineLevel) is much lower and set
>>>> to 9.
>>>> 
>>>> Also, to improve regression test (to considerably speed it up by
>>>> avoiding separate compilation of intermediate lambda forms code) I
>>>> changed behavior of inline command to force inlining of a method when it
>>>> is excluded from compilation.
>>>> 
>>>> Example:
>>>> 
>>>> -XX:CompileCommand=compileonly,DeepInliningTest,m2
>>>> -XX:CompileCommand=inline,java/lang/invoke*,*
>>>> 
>>>> Before:
>>>> DeepInliningTest::m2 (10 bytes)
>>>>  @ 3   java.lang.invoke.LambdaForm$MH/117244645::invokeExact_MT (13
>>>> bytes)   excluded by CompilerOracle
>>>>  @ 6   java.lang.Boolean::booleanValue (5 bytes)   excluded by
>>>> CompilerOracle
>>>> 
>>>> After:
>>>> DeepInliningTest::m2 (10 bytes)
>>>>  @ 3   java.lang.invoke.LambdaForm$MH/1459672753::invokeExact_MT (13
>>>> bytes)   force inline by annotation
>>>>    @ 2   java.lang.invoke.Invokers::checkExactType (30 bytes)   force
>>>> inline by annotation
>>>>      @ 11   java.lang.invoke.MethodHandle::type (5 bytes)   not
>>>> compilable (disabled)
>>>>      @ 25   java.lang.invoke.Invokers::newWrongMethodTypeException (36
>>>> bytes)   force inline by CompileOracle
>>>>        @ 8   java.lang.StringBuilder::<init> (7 bytes)   excluded by
>>>> CompilerOracle
>>>> ...
>>>>    @ 9   java.lang.invoke.LambdaForm$MH/485041780::convert (21 bytes)
>>>>  force inline by annotation
>>>>      @ 5   java.lang.invoke.LambdaForm$MH/1072601481::convert (22
>>>> bytes)   force inline by annotation
>>>> ...
>>>> 
>>>> Testing: regression test, octane, JPRT (in progress)
>>>> 
>>>> Best regards,
>>>> Vladimir Ivanov
>>>> 
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8012941
>