8384052: [lworld] Default refined klass invariant in ObjArrayKlass::klass_from_description is broken#2406
8384052: [lworld] Default refined klass invariant in ObjArrayKlass::klass_from_description is broken#2406TobiHartmann wants to merge 6 commits into
Conversation
|
👋 Welcome back thartmann! A progress list of the required criteria for merging this PR into |
|
/contributor add @fparain |
|
@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: 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
Please see this link for an up-to-date comparison between the source branch of this pull request and the ➡️ To integrate this PR with the above commit message to the |
|
@TobiHartmann |
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 || |
There was a problem hiding this comment.
Unrelated fix for an issue I hit during debugging.
fparain
left a comment
There was a problem hiding this comment.
LGTM
Thank you for finding this bug and taking care of the fix.
|
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. |
|
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. |
|
/integrate |
|
Going to push as commit cadae12.
Your commit was automatically rebased without conflicts. |
|
@TobiHartmann Pushed as commit cadae12. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
#2390 triggered some weird failures and it turned out that this invariant is broken when
ValueClass.newReferenceArrayis called before the default refined klass is created:valhalla/src/hotspot/share/oops/objArrayKlass.cpp
Lines 410 to 414 in 7558cd7
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_klassreturning the wrong refined klass and thus to wrong results with the_copyOfand_newArrayintrinsics.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
Issue
Reviewers
Contributors
<fparain@openjdk.org>Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/valhalla.git pull/2406/head:pull/2406$ git checkout pull/2406Update a local copy of the PR:
$ git checkout pull/2406$ git pull https://git.openjdk.org/valhalla.git pull/2406/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 2406View PR using the GUI difftool:
$ git pr show -t 2406Using diff file
Download this PR as a diff file:
https://git.openjdk.org/valhalla/pull/2406.diff
Using Webrev
Link to Webrev Comment