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

[Vladimir Ivanov]

No problem, I'll make it a develop flag.

Vladimir, Chris, thank you for review.

Best regards,
Vladimir Ivanov

On 10/15/13 1:12 AM, Christian Thalinger wrote:
>
> 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
>>
>