Request for reviews (XXS): 6868269 CompileTheWorld assertion failure introduced by the reexecute bit implementation
Thomas.Rodriguez at Sun.COM
Tue Aug 4 10:56:15 PDT 2009
That seems cleaner to me.
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 Kozlov wrote:
>> changpeng fang - Sun Microsystems - Santa Clara United States wrote:
>>> 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
>>> - if (p->_reexecute != q->_reexecute) return false;
>>> Tests: JPRT, CompileTheWorld!
More information about the hotspot-compiler-dev