RFR: 8158639: C2 compilation fails with SIGSEGV

[Jamsheed C m]

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
>>>>>
>>>>>
>>>>>
>>>
>