Skip to content

8384052: [lworld] Default refined klass invariant in ObjArrayKlass::klass_from_description is broken#2406

Closed
TobiHartmann wants to merge 6 commits into
openjdk:lworldfrom
TobiHartmann:JDK-8384052
Closed

8384052: [lworld] Default refined klass invariant in ObjArrayKlass::klass_from_description is broken#2406
TobiHartmann wants to merge 6 commits into
openjdk:lworldfrom
TobiHartmann:JDK-8384052

Conversation

@TobiHartmann
Copy link
Copy Markdown
Member

@TobiHartmann TobiHartmann commented May 7, 2026

#2390 triggered some weird failures and it turned out that this invariant is broken when ValueClass.newReferenceArray is called before the default refined klass is created:

// Make sure that the first entry in the linked list is always the default refined klass because
// C2 relies on this for a fast lookup (see LibraryCallKit::load_default_refined_array_klass).
ArrayDescription default_ad = array_layout_selection(element_klass(), ArrayProperties::Default());
first = allocate_klass_from_description(default_ad, CHECK_NULL);
release_set_next_refined_klass(first);

In that case, the first entry in the linked list will not be the default refined klass but the not-flat, nullable variant. This leads to the code emitted by LibraryCallKit::load_default_refined_array_klass returning the wrong refined klass and thus to wrong results with the _copyOf and _newArray intrinsics.

I added a targeted regression test for this that covers both intrinsics and randomizes the order in which refined klasses are created.

The fix was provided by @fparain.

Thanks,
Tobias



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-8384052: [lworld] Default refined klass invariant in ObjArrayKlass::klass_from_description is broken (Bug - P3)

Reviewers

Contributors

  • Frederic Parain <fparain@openjdk.org>

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 2406

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

Using diff file

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

Using Webrev

Link to Webrev Comment

@TobiHartmann TobiHartmann marked this pull request as ready for review May 7, 2026 07:49
@bridgekeeper
Copy link
Copy Markdown

bridgekeeper Bot commented May 7, 2026

👋 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.

@TobiHartmann
Copy link
Copy Markdown
Member Author

/contributor add @fparain

@openjdk
Copy link
Copy Markdown

openjdk Bot commented May 7, 2026

@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:

8384052: [lworld] Default refined klass invariant in ObjArrayKlass::klass_from_description is broken

Co-authored-by: Frederic Parain <fparain@openjdk.org>
Reviewed-by: fparain

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:

  • 31ee5a8: 8383991: [lworld] C2: assert(InlineUnsafeOps || StressReflectiveCode) failed: indeterminate pointers come only from unsafe ops
  • 4b95be2: 8383565: [lworld] NativeNMethodBarrier does not correctly handle multiple entry points
  • 46dafa3: 8380059: [lworld] zero: java/foreign/enablenativeaccess/TestEnableNativeAccessJarManifest.java failed with SIGSEGV in InterpreterRuntime::write_flat_field

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.

@openjdk openjdk Bot added the rfr Pull request is ready for review label May 7, 2026
@openjdk
Copy link
Copy Markdown

openjdk Bot commented May 7, 2026

@TobiHartmann
Contributor Frederic Parain <fparain@openjdk.org> successfully added.

@mlbridge
Copy link
Copy Markdown

mlbridge Bot commented May 7, 2026

Webrevs

int cop = cmp->Opcode();
if( cop == Op_FastLock || cop == Op_FastUnlock ||
cmp->is_SubTypeCheck() || cop == Op_VectorTest ) {
if (cop == Op_FastLock || cop == Op_FastUnlock || cop == Op_FlatArrayCheck ||
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unrelated fix for an issue I hit during debugging.

Copy link
Copy Markdown
Collaborator

@fparain fparain left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM
Thank you for finding this bug and taking care of the fix.

@openjdk openjdk Bot added the ready Pull request is ready to be integrated label May 7, 2026
@TobiHartmann
Copy link
Copy Markdown
Member Author

Thanks Fred! The test still triggers an intermittent issue that I'm investigating and I'll therefore hold off with integration until I found the root cause.

@TobiHartmann
Copy link
Copy Markdown
Member Author

The logic in the copyOf intrinsic is broken and should be re-worked with JDK-8251971. I removed the old logic and added (too strong) checks.

@TobiHartmann
Copy link
Copy Markdown
Member Author

/integrate

@openjdk
Copy link
Copy Markdown

openjdk Bot commented May 8, 2026

Going to push as commit cadae12.
Since your change was applied there have been 4 commits pushed to the lworld branch:

Your commit was automatically rebased without conflicts.

@openjdk openjdk Bot added the integrated Pull request has been integrated label May 8, 2026
@openjdk openjdk Bot closed this May 8, 2026
@openjdk openjdk Bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels May 8, 2026
@openjdk
Copy link
Copy Markdown

openjdk Bot commented May 8, 2026

@TobiHartmann Pushed as commit cadae12.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

integrated Pull request has been integrated

Development

Successfully merging this pull request may close these issues.

2 participants