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

[changpeng fang - Sun Microsystems - Santa Clara United States]

http://cr.openjdk.java.net/~cfang/6868269/webrev.00/

Done! I modified the implementation of reexecute bit for Object.clone 
and Arrays.copyOf intrinsics,
and kept the assertion in JVMState::same_calls_as. This means we should 
expect only one reexecute
state for a particular bci.

Thanks,

Changpeng


On 08/04/09 10:56, Tom Rodriguez wrote:
> 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
>>>>
>