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

[Jamsheed C m]

Hi Roland,

On 6/1/2016 6:26 PM, Roland Westrelin wrote:
> I noticed you added a
> test case (DeoptReallocFailureUncommonTrap). Is that one expected to
> fail with the same assert as well? I tried it but it seems to run fine.
no its not expected to give same assert. as exception handling and 
poping will not work as in case of non uncommon_trap case.

uncommon_trap case don't have exception handling and return pc is never 
set to Interpreter::_rethrow_exception_entry. so normal execution will 
continue with (failed realloc) interpreter frames.

classloading will be triggered here in failed realloc execution. may be 
it will again throw exception, which clears pending_exception field and 
rethrow. may be poping starts here(whihc will work fine) but incorrect.

> Backing up a bit: the issue triggered by your other test case is that
> when the deoptimization mode is Unpack_exception,
> vframeArrayElement::unpack_on_stack() forces the return to the
> interpreter to not go through the deopt entries but straight to the
> exception handling code with a pending exception and that's what's
> causing the assert to fire, right?
no, it goes through deopt entries , but as pending exception is set 
return from InterpreterRuntime::exception_handler_for_exception forwards 
exception again to Interpreter::_rethrow_exception_entry.
at this point *do_not_unlock_if_synchronized is set, pop_count is 
decremented by one*. so same deopt frame will again come in 
rethrow_exception_handler context with frames_to_pop_failed_realloc none.

this will go for normal handling, with *do_not_unlock_if_synchronized is 
set. which throws assert.

Best Regards,
Jamsheed
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160601/f5a743da/attachment-0001.html>