RFR: 8146416: java.lang.OutOfMemoryError triggers: assert(current_bci == 0) failed: bci isn't zero for do_not_unlock_if_synchronized

Jamsheed C m jamsheed.c.m at oracle.com
Wed May 25 09:46:46 UTC 2016


Hi Roland,

On 5/25/2016 1:17 PM, Roland Westrelin wrote:
> Hi Jamsheed,
>
>> bug id :https://bugs.openjdk.java.net/browse/JDK-8146416
>> webrev: http://cr.openjdk.java.net/~jcm/8146416/
>> testing: rbt pit, jprt;
> With the change from 6898462, when we hit a OOME during deoptimization,
> we're supposed to go back to the interpreter and pop all
> just-deoptimized interpreter frames. When we go back to the interpreter
>   TemplateInterpreterGenerator::generate_deopt_entry_for() checks for a
> pending exception. Why do we need to check in the uncommon trap blob then?
in exception triggered deopt, the interpreter continuation pc will be  
Interpreter::_rethrow_exception_entry without the pending_exception flag 
reset*(the realloc set pending exception flag).
this causes code to take different path after 
InterpreterRuntime::exception_handler_for_exception(as pending_exception 
is still set). and pop frame logic doesnt work.

and in case of single frame case deopt. pop never happens and 
do_not_unlock_if_synchronized is not made false.

even in TemplateInterpreterGenerator::generate_deopt_entry_for case 
pending exception is not expected!

see..
  // handle exceptions

   {
     Label L;
     __ cmpptr(Address(thread, Thread::pending_exception_offset()), (int32_t) NULL_WORD);
     __ jcc(Assembler::zero, L);
     __ call_VM(noreg,
                CAST_FROM_FN_PTR(address,
                                 InterpreterRuntime::throw_pending_exception));
     __ should_not_reach_here();
     __ bind(L);
   }

>
> With your test case, can the failure be reproduced with c2?
Yes.

Thank you
Jamsheed
> Roland.



More information about the hotspot-compiler-dev mailing list