The original failure was in `test21` from `compiler/valhalla/inlinetypes/TestNullableInlineTypes.java#id5`. I extracted it into a standalone reproducer.
C2 asserts in `InlineTypeNode::field_value_by_offset` while looking up a field value by offset. The lookup reaches a flat field whose corresponding input is already `TOP`. This happens on the normal return path from `test2()` in `test()`. That path is dead because `test2()` always throws a `NullPointerException` when it tries to initialize a null restricted field with null. We only "know" this after incremental inlining though. So at this point, with `-XX:+StressIGVN`, the impossible control path has not been removed yet, but the data path has already started dying: field values on the dead `InlineTypeNode` have been replaced by `TOP`. `InlineTypeNode::field_value_by_offset` already accounts for this with a `value->is_top()` check, but the offset assert in that case is too strict. In this reproducer, the lookup is recursive: it asks for a field inside a flat field whose value is already `TOP`. Therefore, the requested offset is the offset of a nested field within the flattened payload, while `field->offset_in_bytes()` is the offset of the enclosing flat field. Those offsets are not expected to match. I adjusted the assert accordingly. Thanks, Tobias --------- - [x] I confirm that I make this contribution in accordance with the [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). ------------- Commit messages: - JDK-8384202 Changes: https://git.openjdk.org/valhalla/pull/2433/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=2433&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8384202 Stats: 103 lines in 2 files changed: 102 ins; 0 del; 1 mod Patch: https://git.openjdk.org/valhalla/pull/2433.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2433/head:pull/2433 PR: https://git.openjdk.org/valhalla/pull/2433
