-
Notifications
You must be signed in to change notification settings - Fork 5.8k
8302795: Shared archive failed on old version class with jsr bytecode #12752
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
8302795: Shared archive failed on old version class with jsr bytecode #12752
Conversation
/label add hotspot-runtime |
👋 Welcome back ccheung! A progress list of the required criteria for merging this PR into |
@calvinccheung |
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.
Sorry I'm having a little trouble following the problem and solution here. The problem IIUC:
- If we load a class with JSR bytecodes then we have to rewrite those to avoid the use of JSR.
- If we dumped such a class into the shared archive it is in the RO part of the archive.
- If we attempt to rewrite a class in the RO section then we crash.
The solution would seem to be a choice of:
a) don't rewrite the class; or
b) don't archive it
The solution presented here seems to be (a) but I thought we had to rewrite classes with JSR bytecodes ???
Option b is harder to do because we currently cannot link old classes during dump time. So we can't simply do the following check to see is a jsr bytecode is present during dump time. In order to do the above check during dump time, for an "old" class, we'll need to check all the methods and for each method check all the byte codes and see if a jsr bytecode is present. I'll try to implement the above. |
I have pushed a commit. The fix is make the _methods array writable during dump time for "old" classes with the jsr byte code. |
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'm not familiar enough with CDS to review this in detail sorry. The approach sounds reasonable.
Thanks
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.
LGTM. We know after 49.0 (java 5), jsr will not be generated, so this should not be a problem for dynamic dumping too.
@calvinccheung 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 254 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 |
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 makes sense, rewriting the method should rewrite the JSR bytecodes and any matching RET bytecodes. LGTM!
Thanks @yminqi and @matias9927 for the review. /integrate |
Going to push as commit 830fd41.
Your commit was automatically rebased without conflicts. |
@calvinccheung Pushed as commit 830fd41. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
Please review this simple fix for avoid writing in to CDS archive during runtime while loading a shared old class (major_version < 50) with methods containg the jsr byte code.
Otherwise, JVM crashes with the following message in the hs err log:
Error accessing class data sharing archive. Mapped file inaccessible during execution, possible disk/network problem.
Passed tiers 1 - 4 testing.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/12752/head:pull/12752
$ git checkout pull/12752
Update a local copy of the PR:
$ git checkout pull/12752
$ git pull https://git.openjdk.org/jdk pull/12752/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 12752
View PR using the GUI difftool:
$ git pr show -t 12752
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/12752.diff