-
Notifications
You must be signed in to change notification settings - Fork 5.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8301996: Move field resolution information out of the cpCache #14129
Conversation
👋 Welcome back matsaave! A progress list of the required criteria for merging this PR into |
@matias9927 The following label will be automatically applied to this pull request:
When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command. |
@matias9927 this pull request can not be integrated into git checkout field_entry_8301996
git fetch https://git.openjdk.org/jdk.git master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push |
|
3b424ae
to
ea853dc
Compare
Webrevs
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks really good! I have a couple of very minor comments but the rewriter thing I noted should be fixed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From the cursory review, with some comments.
I'll take a closer look once the aarch64 code is in a good shape and see if I can provide a PPC64 implementation. I hope to find time for it in 2 weeks. |
@matias9927 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 181 new commits pushed to the
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 |
Hi, @matias9927, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for addressing the issues that were spotted.
Looks good to me now.
Hi, |
Thank you for your contribution! I really appreciate the help. /contributor add @zifeihan |
@matias9927 |
@matias9927 |
Thank you for your update! |
__ la(temp_reg, Address(temp_reg, in_bytes(ResolvedFieldEntry::put_code_offset()))); | ||
} | ||
// Load-acquire the bytecode to match store-release in ResolvedFieldEntry::fill_in() | ||
__ membar(MacroAssembler::AnyAny); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do you need this membar?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am referencing the mapping from ARM memory operations onto RISC-V memory instructions in riscv-spec [1]:
Since RISC-V does not currently have plain load and store opcodes with aq or rl annotations, ARM load-acquire and store-release operations should be mapped using fences instead. Furthermore, in order to enforce store-release-to-load-acquire ordering, there must be a FENCE RW,RW between the store-release and load-acquire;
So I am trying to be conservative here and added this membar to enforce store-release-to-load-acquire ordering. I can remove that if we are sure this is not necessary here.
__ la(temp, Address(Rcache, in_bytes(ResolvedFieldEntry::put_code_offset()))); | ||
} | ||
// Load-acquire the bytecode to match store-release in ResolvedFieldEntry::fill_in() | ||
__ membar(MacroAssembler::AnyAny); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here.
Thanks for improving readability! An initial PPC64 part is here: TheRealMDoerr@612ee9d. |
Thank you for the PPC port! |
Thank you for the excellent reviews, comments, and suggestions @fparain, @coleenp, @offamitkumar, and @dholmes-ora! Github actions and tier tests show no issues so I believe this change is safe to integrate. |
@matias9927 |
Going to push as commit 86783b9.
Your commit was automatically rebased without conflicts. |
@matias9927 Pushed as commit 86783b9. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
The current structure used to store the resolution information for fields, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields and methods and each of its fields can hold different types of values depending on the entry type.
This enhancement introduces a new data structure that stores the necessary resolution data in an intuitive an extensible manner. These resolved entries are stored in an array inside the constant pool cache in a very similar manner to invokedynamic entries in JDK-8301995.
Instances of ConstantPoolCache entry related to field resolution have been replaced with the new ResolvedFieldEntry. Verified with tier 1-9 tests.
This change supports the following platforms: x86, aarch64, PPC. and RISCV
Progress
Issue
Reviewers
Contributors
<gcao@openjdk.org>
<dzhang@openjdk.org>
<mdoerr@openjdk.org>
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/14129/head:pull/14129
$ git checkout pull/14129
Update a local copy of the PR:
$ git checkout pull/14129
$ git pull https://git.openjdk.org/jdk.git pull/14129/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 14129
View PR using the GUI difftool:
$ git pr show -t 14129
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/14129.diff
Webrev
Link to Webrev Comment