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

[Tom Rodriguez]

That seems cleaner to me.

tom

On Aug 4, 2009, at 10:17 AM, Vladimir Kozlov wrote:

> 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
>>>