[9] RFR(S): 8174164: SafePointNode::_replaced_nodes breaks with irreducible loops

[Vladimir Kozlov]

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
> point?

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?

Vladimir

>
> Roland.
>