[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