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

jamsheed jamsheed.c.m at oracle.com
Tue Sep 12 10:20:49 UTC 2017


Hi Vladimir,

On Tuesday 12 September 2017 12:03 AM, Vladimir Kozlov wrote:
> Jamsheed,
>
> You said you have a small test case. Can you add it as new jtreg test?
ok, i have added the test case in JBS now, it uses -XX:+DTraceMethodProbes.
>
> Can it be reproduced with CompileCommand=dontinline,Object.<init> ?
it reproduces in inline case too.
>
> I don't see RBT testing results.
i will update it.
Best Regards,
Jamsheed
>
> 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
>>
>>



More information about the hotspot-compiler-dev mailing list