Tiered compilation C2 compiler crash.

[Vladimir Kozlov]

So the receiver is NULL pointer. It is strange.

What is call stack at that time? Is for_method_handle_inline() called 
from do_call() or from do_late_inline()?

Can you also show outputs of jvms->dump(), caller->print(), 
callee->print() ?

Thanks,
Vladimir


On 9/19/14 11:45 AM, MacGregor, Duncan (GE Energy Management) wrote:
> Sorry for the delay, lots of other stuff in progress right now. The
> fastdebug build with asserts was too slow to start the application with,
> so I made a debug build with asserts disabled.and got the following.
>
> --Node dump--
>   162    ConP    ===  0  [[ 163  171  218  265  272  286  311  359  399
> 408  474
>    481  525  570  577  591  615  663  703  711  468  739  754  770  769
> 801  857
>    865  865  1457  1467  1475  1892  1902  1910  2278  2360  2368  2404
> 2411  24
> 33  2470  2478  2485  2511  2517  2396  2653  2732  2740  2775  2782  2804
>   2841
>    2849  2856  2882  2888  2767  3079  3087  3518  3525  3568  3613  3620
> 3634
> 3658  3706  3745  3753  3817  3824  3867  3912  3919  3933  3957  4005
> 4044  40
> 52  3811  4080  4093  4107  4106  4137  4297  4305  4701  4788  4796  4831
>   4838
>    4860  4899  4907  4914  4942  4948  4823  5176  5186  5194  5653  5660
> 5703
> 5748  5755  5769  5793  5841  5880  5888  5952  5959  6002  6047  6054
> 6068  60
> 92  6140  6179  6187  5946  6215  6228  6242  6241  6272  6434  6444  6452
>   6911
>    6921  6929  7226  7224  7239  7239  7246  7317  7395  7403  7439  7446
> 7468
> 7505  7513  7520  7546  7552  7431  7750  7760  7768  8187  8194  8237
> 8282  82
> 89  8303  8327  8375  8414  8422  8486  8493  8536  8581  8588  8602  8626
>   8674
>    8713  8721  8480  8749  8762  8776  8775  8806  8954  8964  8972  9429
> 9439
> 9447  9744  9742  9756  9756  9763  9834  9912  9920  9956  9963  9985
> 10022  1
> 0030  10037  10063  10069  9948  10255  10265  10273  10731  10741  10749
> 11094
>    11138  11145  11066  11042  11173  11037  11180  11188  11190  11190
> 11192  1
> 1192  11187  11182  11200  11201  11209  11211  11215  11233  11235  11238
> ]]  #
> NULL
> --Type dump--
> NULL
> --Targer print--
> <ciMethod name=getWrappedSlotProvider
> holder=com/gesmallworld/magik/runtime/obje
> cts/SlottedProxy
> signature=(Ljava/lang/Integer;)Lcom/gesmallworld/magik/runtime/
> objects/SlotProvider; loaded=true arg_size=2 flags=public ident=1407
> address=0x0
> 00000005d7c3f70>
>
>  From grepping through type.cpp I¹m guessing the type is a TypePtr of some
> form, but dump() doesn¹t output much in the null case.
>
>
> One of my colleagues has also reported this issue with
> -XX:-TieredCompilation, and the error log shows the same offsets in
> jvm.dll so I¹m guessing tiered comp just lets me provoke the issue more
> quickly. I¹ve now found a faster route through the application to trigger
> this, so it¹s going to be much less painful to run any further tests you
> suggest.
>
> Cheers,
> Duncan.
>
> On 17/09/2014 17:53, "Vladimir Kozlov" <vladimir.kozlov at oracle.com> wrote:
>
>> Hi Duncan
>>
>> In debug version of VM there is Node::dump(n) method which prints ideal
>> nodes.
>> Can you show output of call receiver_node->dump(1)?
>> And also output of gvn.type(receiver_node)->dump() to see type in IGVN.
>> And target->print() which prints method descriptor.
>>
>> Thanks,
>> Vladimir
>>
>> On 9/17/14 2:30 AM, MacGregor, Duncan (GE Energy Management) wrote:
>>> We¹ve been seeing many cases of a C2 compiler crash which is happening
>>> on 8u20 with tiered compilation and heavy use of invokeDynamic. It is
>>> somewhat intermittent but the same method is always at the end of the
>>> compilation replay log, and it is always happening at the same spot on
>>> jvm.dll.
>>>
>>> I¹ve done some work on narrowing down the problem and it appears that
>>> it¹s occurring in CallGenerator.for_method_handle_inline() line 856
>>> where it retrieves the receiver type from the PhaseGVN. It assumes that
>>> the receiver is an ooopptr, but the type I¹m getting back is actually an
>>> anyptr so the isa_oopptr() method returns null, and I then get an access
>>> violation at line 865 when the code attempts to call speculate_type().
>>>
>>> Is it ever valid for a non-oop ptr to be the receiver type, and if not
>>> does anybody have a good suggestion for where to try and catch this type
>>> being put into the PhaseGVN?
>>>
>>> Thanks, Duncan.
>>>
>