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
8295029: runtime/cds/appcds/LotsOfClasses.java fail with jfx #10708
Conversation
👋 Welcome back coleenp! A progress list of the required criteria for merging this PR into |
Yes, the testcase needs to simulate a large number of (about 60189 - 49191) classes just like import javafx modular. 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. I agree that if the test is too hard to write (it depends on the exact names of classes being loaded) then we can skip it, because the code change is pretty simple -- it removes a special case for java -Xshare:dump
. The effect of the removal will be tested by all the tests that dumps a CDS archive.
@coleenp 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 101 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.
LGTM.
So the only one type of dictionary that gains the super powers of resizing is the DelegatingClassLoader dictionary, but based on comments it's always size 1, so it never will need to be resized? Related question, but not part of this fix - can we simplify things and not have to bother with 1 element dictionary for DelegatingClassLoader somehow? |
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
Thanks for the reviews, Ioi, Calvin and Gerard. |
Going to push as commit 37f93b6.
Your commit was automatically rebased without conflicts. |
This removes the can-resize parameter for ClassLoaderData dictionaries. They can all resize now that the shared dictionaries are moved to the CompactHashtable. This also removes an unused/untested development option to disallow resizing.
Tested with tiers1-4 and tested with the failing test case. It can't be added because it requires outside code or simulated because it would be an expensive test to generate all those class files. There's an existing test for resizing.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/10708/head:pull/10708
$ git checkout pull/10708
Update a local copy of the PR:
$ git checkout pull/10708
$ git pull https://git.openjdk.org/jdk pull/10708/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 10708
View PR using the GUI difftool:
$ git pr show -t 10708
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/10708.diff