RFR(S): 8174164: SafePointNode::_replaced_nodes breaks with irreducible loops
rwestrel at redhat.com
Thu Feb 9 19:31:49 UTC 2017
> The scenario I am concern with is next. Assuming that replacement
> happened in callee, for example, due to class check where one branch
> will go into UNC Trap. But at the same time node representing klass
> constant (CheckCastPP) is already present in caller (used for an other
> not related nodes). As result you will get 'improved' node as old node
> and it will not pass your new condition. So what happens in such case?
> Will we able to make replacement?
If the CheckCastPP is in the caller, then replace_in_map replaces the
input of the CheckCastPP with the CheckCastPP in the caller's map. That
improvement is done before the callee is called so is valid in the
callee too. When parsing exits the callee, no replacement happens
(CheckCastPP is not a new node in the callee) but there shouldn't be any
to do because replace_in_map already modified the caller's map before
the callee was parsed. When parsing exits the caller, replacement
happens in the caller's caller map (the CheckCastPP is a new node). So
the caller's caller, the caller and the callee should all see the
improved nodes, right?
More information about the hotspot-compiler-dev