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

Christian Thalinger cthalinger at twitter.com
Mon Sep 11 18:17:09 UTC 2017


> On Sep 11, 2017, at 8:13 AM, jamsheed <jamsheed.c.m at oracle.com> wrote:
> 
> Hi,
> 
> request for review the fix made for the bug
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8168712 <https://bugs.openjdk.java.net/browse/JDK-8168712>

Any chance to make that bug open?

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20170911/b8e356f7/attachment-0001.html>


More information about the hotspot-compiler-dev mailing list