Request for reviews (XXS): 6868269 CompileTheWorld assertion failure introduced by the reexecute bit implementation

[Vladimir Kozlov]

So after discussion with Changpeng I now understand what happened.
The path which don't have reexecute state is uncommon trap
in null_check_receiver() at the beginning of inline_native_clone()
because it is not in the PreserveReexecuteState scope.
So the other solution of this bug is including null_check_receiver()
into the PreserveReexecuteState scope.

Vladimir

Vladimir Kozlov wrote:
> Good.
> 
> Vladimir
> 
> changpeng fang - Sun Microsystems - Santa Clara United States wrote:
>> http://cr.openjdk.java.net/~cfang/6868269/webrev.00/
>>
>> Problem: For inline_native_clone, there are two exceptions with 
>> different reexecute states.
>> This caused the assertion on JVMState::same_calls_as
>>
>> Solution: JVMState::same_calls_as was designed to verify the same 
>> method/bci pairs. The current
>> implementation of reexecute logic does not require the same method/bci 
>> to have a single reexecute
>> state, i.e. the implementer could change the reexecute state during 
>> the parsing of a bci.
>>
>> So the solution is simply remove the following line in 
>> JVMState::same_calls_as:
>>
>> -     if (p->_reexecute != q->_reexecute)  return false;
>>
>>
>>
>> Tests: JPRT, CompileTheWorld!
>>
>>
>>
>> Thanks,
>>
>>
>> Changpeng
>>