[10] RFR: [AOT] assert(false) failed: DEBUG MESSAGE: InterpreterMacroAssembler::call_VM_base: last_sp != NULL

[Christian Thalinger]

> On Sep 11, 2017, at 8:33 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> Jamsheed,
> 
> You said you have a small test case. Can you add it as new jtreg test?
> 
> Can it be reproduced with CompileCommand=dontinline,Object.<init> ?
> 
> I don't see RBT testing results.
> 
> Here is Dean's evaluation:
> 
> "This crash happens because of the code in TemplateInterpreter::deopt_reexecute_entry() that uses _normal_table.entry() instead of AbstractInterpreter::deopt_reexecute_entry() if we are at a return bytecode. Normally C1 and C2 inline and use an intrinsic for Object.<init>, so there is little chance to deoptimize on a return bytecode. But with AOT-compiled Object.<init> it's possible, and we assert because we skipped the deopt entry that is supposed to clear last_sp. “

Thanks.

> 
> Thanks,
> Vladimir
> 
> On 9/11/17 11:13 AM, jamsheed wrote:
>> Hi,
>> request for review the fix made for the bug
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8168712
>> webrev: http://cr.openjdk.java.net/~jcm/8168712/webrev.00/
>> brief desc: special handling of Object.<init> in TemplateInterpreter::deopt_reexecute_entry
>> required last_sp to be reset explicitly in normal return path
>> address TemplateInterpreter::deopt_reexecute_entry(Method* method, address bcp) {
>>   assert(method->contains(bcp), "just checkin'");
>>   Bytecodes::Code code   = Bytecodes::java_code_at(method, bcp);
>>   if (code == Bytecodes::_return) {
>>     // This is used for deopt during registration of finalizers
>>     // during Object.<init>.  We simply need to resume execution at
>>     // the standard return vtos bytecode to pop the frame normally.
>>     // reexecuting the real bytecode would cause double registration
>>     // of the finalizable object.
>>     return _normal_table.entry(Bytecodes::_return).entry(vtos);
>> test: jprt
>> Best Regards,
>> Jamsheed