RFR: 8158639: C2 compilation fails with SIGSEGV

[Vladimir Kozlov]

Got it. Thank you for explanation.

Vladimir

On 8/22/16 9:34 PM, Jamsheed C m wrote:
> The bug was very intermittent without excluding run method, as most of the time it took this path
>
> Best Regards,
>
> Jamsheed
> On 8/23/2016 10:00 AM, Jamsheed C m wrote:
>> Hi Vladimir,
>>
>> it was falling under receiver always null special case, which was already handling this
>>
>> JVMState* VirtualCallGenerator::generate(JVMState* jvms) {
>>   GraphKit kit(jvms);
>>   Node* receiver = kit.argument(0);
>>
>>   kit.C->print_inlining_update(this);
>>
>>   if (kit.C->log() != NULL) {
>>     kit.C->log()->elem("virtual_call bci='%d'", jvms->bci());
>>   }
>>
>>   // If the receiver is a constant null, do not torture the system
>>   // by attempting to call through it.  The compile will proceed
>>   // correctly, but may bail out in final_graph_reshaping, because
>>   // the call instruction will have a seemingly deficient out-count.
>>   // (The bailout says something misleading about an "infinite loop".)
>>   if (kit.gvn().type(receiver)->higher_equal(TypePtr::NULL_PTR)) {
>>     assert(Bytecodes::is_invoke(kit.java_bc()), "%d: %s", kit.java_bc(), Bytecodes::name(kit.java_bc()));
>>     ciMethod* declared_method = kit.method()->get_method_at_bci(kit.bci());
>>     int arg_size = declared_method->signature()->arg_size_for_bc(kit.java_bc());
>>     kit.inc_sp(arg_size);  // restore arguments
>>     kit.uncommon_trap(Deoptimization::Reason_null_check,
>>                       Deoptimization::Action_none,
>>                       NULL, "null receiver");
>>     return kit.transfer_exceptions_into_jvms();
>>   }
>>
>> Best Regards,
>> Jamsheed
>> On 8/23/2016 9:46 AM, Vladimir Kozlov wrote:
>>> Jamsheed, code changes are good. But why you excluded run() method from compilation? The problem happened exactly
>>> dutin this method compilation.
>>>
>>> Thanks,
>>> Vlaidimir
>>>
>>> On 8/22/16 9:09 PM, Jamsheed C m wrote:
>>>> Hi Vladimir,
>>>>
>>>> revised webrev with comments: http://cr.openjdk.java.net/~jcm/8158639/webrev.01/index.html
>>>>
>>>> i had updated pit link yesterday night itself, but somehow it didn't work. updated it now again.
>>>>
>>>> Best Regards,
>>>>
>>>> Jamsheed
>>>>
>>>>
>>>> On 8/22/2016 11:36 PM, Vladimir Kozlov wrote:
>>>>> Changes seems fine. Please, add comments in changes.
>>>>>
>>>>> Jamsheed, did you run RBT? I don't see a link in the bug report.
>>>>>
>>>>> Thanks,
>>>>> Vladimir
>>>>>
>>>>> On 8/22/16 5:28 AM, Jamsheed C m wrote:
>>>>>> Hi,
>>>>>>
>>>>>> bug id:https://bugs.openjdk.java.net/browse/JDK-8158639 <https://bugs.openjdk.java.net/browse/JDK-8158639>
>>>>>> webrev:http://cr.openjdk.java.net/~jcm/8158639/webrev.00/ <http://cr.openjdk.java.net/%7Ejcm/8158639/webrev.00/>
>>>>>>
>>>>>> Request for review.
>>>>>>
>>>>>> Description
>>>>>> _linkTo* adapter elimination  in C2 cause wrong jvms  for null checks at callsite. which makes MemberName missing for
>>>>>> trap and reexecute at these sites.
>>>>>>
>>>>>> and in reported bug, this makes wrong data getting loaded in profile data for trap and reexecute.and later getting
>>>>>> crash at recompilation.
>>>>>>
>>>>>> Fix: fix the jvms based on _linkTo*(Declared method signature ) at these trap sites.
>>>>>>
>>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> Jamsheed
>>>>>>
>>>>>>
>>>>>>
>>>>
>>
>