RFR (S): 8011138: C2: stack overflow in compiler thread because of recursive inlining of lambda form methods
Christian Thalinger
christian.thalinger at oracle.com
Fri Oct 4 09:54:42 PDT 2013
Thank you, Vladimir.
On Oct 4, 2013, at 8:54 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> Good.
>
> Vladimir
>
> On 10/3/13 6:37 PM, Christian Thalinger wrote:
>>
>> On Oct 3, 2013, at 5:44 PM, Vitaly Davidovich <vitalyd at gmail.com <mailto:vitalyd at gmail.com>> wrote:
>>
>>> Chris, you can move is_compiled_lambda_form() a block higher and use it there as well :).
>>>
>> Holy! What is it with you guys… ;-)
>>
>> Done.
>>
>> http://cr.openjdk.java.net/~twisti/8011138/webrev.04/
>>>
>>> Sent from my phone
>>>
>>> On Oct 3, 2013 8:39 PM, "Christian Thalinger" <christian.thalinger at oracle.com <mailto:christian.thalinger at oracle.com>>
>>> wrote:
>>>
>>>
>>> On Oct 3, 2013, at 3:29 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
>>>
>>> > On 10/3/13 3:11 PM, Christian Thalinger wrote:
>>> >>
>>> >> On Oct 3, 2013, at 2:31 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
>>> >>
>>> >>> Christian,
>>> >>>
>>> >>> Put callee_method->is_compiled_lambda_form() and jvms->map()->argument(jvms, 0)->uncast() into local vars
>>> outside loop since they are invariants.
>>> >>
>>> >> Invariants, exactly. That's why the compiler should do it for me. We are compiler people; we should trust
>>> compilers.
>>> >
>>> > I don't trust compilers BECAUSE I am compiler guy and I know their problems :)
>>> > If calls are not inlined (virtual or other reasons) they will not be moved from the loop.
>>> >
>>> > And you should know already that the best performance improvement come from changing sources and not from
>>> compilers :)
>>> >
>>> > I insist to move at least callee_argument0 outside the loop.
>>>
>>> The code was easier to understand before but your wish is my command:
>>>
>>> http://cr.openjdk.java.net/~twisti/8011138/webrev.03/
>>>
>>> >
>>> > Vladimir
>>> >
>>> >>>
>>> >>> Also both branches have to check (j->method() == callee_method). It could be checked first:
>>> >>>
>>> >>> if (j->method() == callee_method) {
>>> >>> if (callee_is_compiled_lambda_form) {
>>> >>> // Since compiled lambda forms are heavily reused we allow recursive inlining.
>>> >>> // If it is truly a recursion (using the same "receiver") we limit inlining
>>> >>> // otherwise we can easily blow the compiler stack.
>>> >>> Node* caller_argument0 = j->map()->argument(j, 0)->uncast();
>>> >>> if (caller_argument0 == callee_argument0) {
>>> >>> inline_level++;
>>> >>> }
>>> >>> } else {
>>> >>> inline_level++;
>>> >>> }
>>> >>> }
>>> >>
>>> >> Good point.
>>> >>
>>> >> http://cr.openjdk.java.net/~twisti/8011138/webrev.02/
>>> >>
>>> >>>
>>> >>> Thanks,
>>> >>> Vladimir
>>> >>>
>>> >>> On 10/3/13 1:41 PM, Christian Thalinger wrote:
>>> >>>>
>>> >>>> On Oct 3, 2013, at 11:28 AM, Roland Westrelin <roland.westrelin at oracle.com
>>> <mailto:roland.westrelin at oracle.com>> wrote:
>>> >>>>
>>> >>>>>>> You should probably use:
>>> >>>>>>> caller_argument0->uncast() == callee_argument0->uncast()
>>> >>>>>>
>>> >>>>>> I can but it's probably not necessary. If it's truly a recursive call even the CheckCastPP node should be
>>> the same, right?
>>> >>>>>
>>> >>>>> With 8024070, that will add Cast nodes in many places, I don't think that will necessarily be the case.
>>> >>>>
>>> >>>> Fair enough. I've added the uncast() calls:
>>> >>>>
>>> >>>> http://cr.openjdk.java.net/~twisti/8011138/webrev.01/
>>> >>>>
>>> >>>>>
>>> >>>>> Roland.
>>> >>>>
>>> >>
>>>
>>
More information about the hotspot-compiler-dev
mailing list