RFR(S): 8174164: SafePointNode::_replaced_nodes breaks with irreducible loops
vladimir.kozlov at oracle.com
Thu Feb 9 18:56:11 UTC 2017
On 2/9/17 1:38 AM, Roland Westrelin wrote:
>>>> Also what happens for the rest of replacing nodes on the list?
>>> They stay on the list. I suppose I could prune the list when it's
>>> propagated from a callee to a caller.
>> Can you put old nodes pruned from list on IGVN list so they have chance
>> to be optimized later?
> Actually, no, thinking more about this, I don't see how the list can be
> pruned more than it is today. The code collects (initial, improved)
> pairs of nodes every time replace_in_map is called. Then, at parse time,
> on method exit, the list of pairs is passed to the caller and nodes on
> the current safepoint state are replaced. ReplacedNodes::transfer_from()
> already has some pruning (pairs for which initial is a new node in a
> callee are not passed to the caller). I don't see what other nodes can
> be removed because we're sure they can't be candidates for replacement
> in callers. I don't think wether improved is new in a callee tells us
> anything about whether it can be replaced in a caller or not. Also, I
> don't think I understand why we would want to push nodes on the igvn
> list: assuming all those nodes are control dependent CheckCastPP or
> CastPP nodes, why do we think they can be optimized further at this
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?
More information about the hotspot-compiler-dev