8384202: [lworld] C2: assert(offset == field->offset_in_bytes()) failed: offset mismatch

[TobiHartmann]

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

---

• I confirm that I make this contribution in accordance with the OpenJDK Interim AI Policy.

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed (1 review required, with at least 1 Committer)

Issue

• JDK-8384202: [lworld] C2: assert(offset == field->offset_in_bytes()) failed: offset mismatch (Bug - P4)

Reviewers

• Marc Chevalier (@marc-chevalier - Committer) ⚠️ Review applies to 426af5ba
• Quan Anh Mai (@merykitty - Committer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/valhalla.git pull/2433/head:pull/2433
$ git checkout pull/2433

Update a local copy of the PR:
$ git checkout pull/2433
$ git pull https://git.openjdk.org/valhalla.git pull/2433/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 2433

View PR using the GUI difftool:
$ git pr show -t 2433

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/valhalla/pull/2433.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back thartmann! A progress list of the required criteria for merging this PR into lworld will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@TobiHartmann This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8384202: [lworld] C2: assert(offset == field->offset_in_bytes()) failed: offset mismatch

Reviewed-by: mchevalier, qamai

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 3 new commits pushed to the lworld branch:

• 6b9eb7d: 8384283: [lworld] Post-parse call devirtualization with unloaded return type fails
• de6aff4: 8384364: [lworld] C2: assert(cloned_flat_array_check->req() == 3) failed: unexpected number of inputs for FlatArrayCheck
• 2d330b1: 8384193: [lworld] Remove identity field from java.lang.Class

Please see this link for an up-to-date comparison between the source branch of this pull request and the lworld branch.
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the lworld branch, type /integrate in a new comment.

[mlbridge]

Webrevs

• 02: Full - Incremental (d4f16a41)
• 01: Full - Incremental (741acf68)
• 00: Full (426af5ba)

[merykitty]

This looks a bit cluttered, can we move if (value->is_top()) into a separate case before this if instead?

[TobiHartmann]

Sure. I had this version first and didn't like it but I don't have a strong opinion. Updated.

[marc-chevalier]

That makes sense. Do we want the bug number in the test?

[marc-chevalier]

The hardcoded is on purpose? It reproduces so rarely otherwise?

[TobiHartmann]

Yes, it's on purpose to make it reliably reproduce the issue and the usual way of how we design these tests. I.e. one run with fixed seed and one without. As we discussed offline, there are several alternatives to this approach, including RepeatCompilation etc. We decided on the current approach a while ago but we can surely revisit. It's out of scope of this PR though 🙂

Testing also revealed that PreloadClasses is required to make sure that the @NullRestricted annotation is respected, so I added a corresponding @requires.

[merykitty]

I think that means this test lacks a test that does not use a fixed seed?

[TobiHartmann]

Thanks for the reviews Quan Anh and Marc! I pushed an updated version.

Do we want the bug number in the test?

I added a bug number to the test.

[merykitty]

Thanks, that looks good to me.