On Wed, 22 Oct 2025 13:55:03 GMT, Christian Hagedorn <[email protected]> 
wrote:

> `TestLWorld.java` was failing intermittently with `-XX:+StressIGVN` and 
> `-XX:+StressLoopPeeling` due to not handling `top` correctly in 
> `InlineTypeNode::merge_with()` during IGVN.
> 
> We have the following graph during IGVN:
> <img width="558" height="304" alt="image" 
> src="https://github.com/user-attachments/assets/6c146038-208f-4f5a-bcfa-5be0d5b67537";
>  />
> 
> The following steps happen:
> 1. `6837 Phi` was created in Loop Peeling to merge data nodes from the peeled 
> iteration and the remaining loop (this is the reason we are only seeing this 
> failure with `StressLoopPeeling` - there are simply more chances with more 
> phis to get unlucky and hit the assert).
> 2. When processing `6837 Phi` in IGVN, we apply 
> `PhiNode::try_push_inline_types_down()` in order to push the `InlineType` 
> nodes down recursively. 
> 3. Doing it recursively, we will then call 
> `PhiNode::try_push_inline_types_down()` on `6535 Phi`.
> 4. We create a new initial `InlineType` node based on the same klass as `6259 
> InlineType` (i.e. the same fields) but use `Phis` for the inputs or 
> `InlineType` nodes if the fields are value objects themselves:
> https://github.com/openjdk/valhalla/blob/abc1d5b2632ea270735f1e5aa794c7ab9e5f2378/src/hotspot/share/opto/inlinetypenode.cpp#L87-L89
> This new `InlineType` node represents the resulting "pushed down" 
> `InlineType`. Let's call it `inline-type-result`.
> 5.  We now populate the phi inputs of `inline-type-result` by visiting the 
> `InlineType` inputs of `6535 Phi`.
> 6. We visit the first input `6259 InlineType`: We update the first input of 
> the phis of `inline-type-result` by calling `merge_with()` on 
> `inline-type-result`.
> 7. We visit all inputs of `inline-type-result`: These are either phis or 
> `InlineType` nodes (see step 4). When we see an `InlineType` input, we must 
> also see an `InlineType` input for `6259 InlineType` because we used the same 
> klass in step 4. However, we miss here that we could also have a top input 
> because the node is actually being removed in IGVN because we only take the 
> other path of `6535 Phi`. Therefore this assumption is wrong:
> https://github.com/openjdk/valhalla/blob/abc1d5b2632ea270735f1e5aa794c7ab9e5f2378/src/hotspot/share/opto/inlinetypenode.cpp#L157-L161
> and we crash because `val2` is top.
> 
> The fix is straight forward to stop the merge since the node is dead. Since 
> this is highly intermittent and occurring with `TestLWorld.java` only, I have 
> not added a separate test case. Additionally to standard testing, I also ran 
> `TestLWorld.java` 100 times in th...

Thanks Tobias for your review!

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1694#issuecomment-3436781011

Reply via email to