[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