Request for reviews (XXS): 6868269 CompileTheWorld assertion failure introduced by the reexecute bit implementation
Vladimir.Kozlov at Sun.COM
Tue Aug 4 10:17:55 PDT 2009
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