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

[Vladimir Kozlov]

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