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

Roland Westrelin rwestrel at redhat.com
Wed Jun 1 12:56:14 UTC 2016


Hi Jamsheed,

> I have made shared only change.
> 
> Revised webrev: http://cr.openjdk.java.net/~jcm/8146416/webrev.01/

Thanks for putting a shared only change together. 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.

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?

Can you explain in details what other issues you're trying to fix?

Roland.

> 
> Best Regards,
> 
> Jamsheed
> 
> 
> On 5/27/2016 7:56 PM, Jamsheed C m wrote:
>> some of the code that may require change
>>
>> this is based on quick grep result.. not based on analysis
>>
>> ...
>>   guarantee(!(thread->deopt_nmethod()->is_compiled_by_c2() &&
>>               *bcp == Bytecodes::_monitorenter &&
>>               exec_mode == Deoptimization::Unpack_exception),
>>             "shouldn't get exception during monitorenter");
>>
>> ...
>>     } else if (JvmtiExport::can_force_early_return() && state != NULL
>> && state->is_earlyret_pending()) {
>>
>> ...
>>
>>     (is_top_frame && (exec_mode == Unpack_exception) &&
>> iframe->interpreter_frame_expression_stack_size() == 0) ||
>>
>>
>> Best Regards,
>> Jamsheed
>> On 5/27/2016 2:52 PM, Jamsheed C m wrote:
>>> My concern is like adding  checks in shared code, would reduce
>>> readability still further..
>>>
>>> for platform change its simple check and forward change, a detailed
>>> comment would do!
>>>
>>> Best Regards,
>>> Jamsheed
>>>
>>> On 5/27/2016 1:13 PM, Roland Westrelin wrote:
>>>> Hi Jamsheed,
>>>>
>>>>> can i go ahead with this change ?
>>>> I still think a shared code only change would be better (unless you
>>>> demonstrate a reasonable shared code change is not possible). What do
>>>> others think?
>>>>
>>>> Roland.
>>>
>>
> 


More information about the hotspot-compiler-dev mailing list