[10] RFR: [AOT] assert(false) failed: DEBUG MESSAGE: InterpreterMacroAssembler::call_VM_base: last_sp != NULL
jamsheed
jamsheed.c.m at oracle.com
Wed Sep 13 01:29:03 UTC 2017
Thank you for review and feedback.
i presumed speed was not issue for interpreter, so went with this
approach, all others need a bit more platform coding or investigation.
Best Regards,
Jamsheed
On Tuesday 12 September 2017 02:52 AM, Dean Long wrote:
> Unfortunately, this fix slows down normal returns, even for non-debug
> builds. Isn't what we really want something like
> deopt_no_reexecute_entry, which would use
> Interpreter::deopt_entry(state, Bytecodes::length_for(code)) to skip
> the current return bytecode?
skip current return bytecode with removal of top frame, right ?
Best regards,
Jamsheed
>
> dl
>
>
> On 9/11/2017 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