-
Notifications
You must be signed in to change notification settings - Fork 5.8k
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
8293532: Use lighter jmod compression levels in build config #10214
Conversation
👋 Welcome back shade! A progress list of the required criteria for merging this PR into |
cfe88a6
to
923c6d5
Compare
The dependent pull request has now been integrated, and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork: git checkout JDK-8293532-jmod-build-lighter
git fetch https://git.openjdk.org/jdk master
git merge FETCH_HEAD
# if there are conflicts, follow the instructions given by git merge
git commit -m "Merge master"
git push |
@shipilev this pull request can not be integrated into git checkout JDK-8293532-jmod-build-lighter
git fetch https://git.openjdk.org/jdk master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push |
923c6d5
to
4f29501
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.
I think the idea of being able to change the jmod compression is good. I'm torn about what a good default is. Maybe keeping a higher compression on release builds would make sense? I'm not sure so would like to hear if there are more opinions on it. There is little point spending time compressing jmods on debug builds at least.
I fully agree with Erik. The idea is good, but what is a suitable default? The patch, as it stands, requires all distributors to update their build scripts to get the same output as they did before the patch. So if we set the default to 6 instead (iiuc), we will get the same default behavior, but we can get a speedup by passing an argument to configure. Normally, my stance would be that configure with few arguments should setup a good developer experience, and that CI systems can afford to add extra flags. In principle I think that should apply here too, but I'm slightly more worried that we might not be able to reach out to everyone affected. Also, if we do end up keeping the default as currently suggested in this PR, we need at least to update the jib-profiles.conf file. |
I think the only mildly controversial part is the default used when creating the packaged modules for the release build. Adding a configure option, creating the interim JMODs with --compress zip-0, and changing the default for debug releases might be okay. |
Alans suggestion seems the safest route for now. We can always come back later and change the default. If you go down this route, please add the new configure option to the GHA files to speed up GHA release builds, as these are not distributed. |
@shipilev Please do not rebase or force-push to an active PR as it invalidates existing review comments. All changes will be squashed into a single commit automatically when integrating. See OpenJDK Developers’ Guide for more information. |
All right then. See new commits:
Sample improvements for
|
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.
Ship it! :)
@shipilev 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 30 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 |
Aye, Capt'n! Any more opinions on this, or we are done? |
Anyone else? |
I think you're fine. The only controversial part was the default, which is now restored to what is was before. |
All right then! /integrate |
Going to push as commit 05c8cab.
Your commit was automatically rebased without conflicts. |
As follow-up to JDK-8293499, JDK build can stick to lighter jmod compression levels to gain build performance.
This gets even more substantial if JVM is configured with
--with-native-debug-symbols=internal
, in which casejava.base
includes a much largerlibjvm.so
:Users can use
--with-jmod-compress=zip-6
to get the original JMOD compression level back. Or, they can give up on compression altogether using--with-jmod-compress=zip-0
, and then reap even more time benefits:Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/10214/head:pull/10214
$ git checkout pull/10214
Update a local copy of the PR:
$ git checkout pull/10214
$ git pull https://git.openjdk.org/jdk pull/10214/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 10214
View PR using the GUI difftool:
$ git pr show -t 10214
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/10214.diff