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

Vladimir Kozlov vladimir.kozlov at oracle.com
Wed Feb 8 18:54:39 UTC 2017

What happens if Identity() was used for replacement and as result new 
node would exist and its idx < _new_idx? Or replacing nodes list records 
only new nodes?

Also what happens for the rest of replacing nodes on the list?


On 2/8/17 7:18 AM, Roland Westrelin wrote:
> http://cr.openjdk.java.net/~roland/8174164/webrev.00/
> Handling of SafePointNode::_replaced_nodes is incompatible with
> irreducible loops: replaced nodes can be propagated and applied before
> all predecessor blocks (on a path to method entry) are processed which
> can lead to a broken graph.
> This was observed by one of our customers (crash in the compiler). The
> compilation in that case is an OSR compilation: OSR compilations can
> cause irreducible loops even if the methods that are compiled have no
> irreducible loops. The test case is an example of that. Note that this
> test case doesn't cause a compiler crash with 9 but it does with 8: with
> 8 static_field() returns a CheckCastPP of a constant to an interface but
> with 9 and because of 8076094, the CheckCastPP is optimized out (the
> checkCastPP of a constant is needed to have the same node when the
> replaced node is recorded and at the call return where replacement
> happens). Reverting 8076094 in 9 is enough to trigger the
> problem. Anyway, I intend to have this backported to 8 so I think the
> test case still has value.
> The solution I propose is to only consider nodes allocated in callees as
> candidates for replacement on method exit: on method exit, the risk is
> that the caller which is not fully parsed has an irreducible loop. The
> callee is fully parsed so even if it has an irreducible loop, there's no
> risk of breaking the graph.
> Roland.

More information about the hotspot-compiler-dev mailing list