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 Jun 1 13:19:37 UTC 2016
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-compiler-dev