-
Notifications
You must be signed in to change notification settings - Fork 6.1k
8356447: Change default for EagerJVMCI to true #25121
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
Conversation
|
👋 Welcome back dnsimon! A progress list of the required criteria for merging this PR into |
|
@dougxc 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 213 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 |
1c1b8d7 to
eab659c
Compare
Webrevs
|
| if (FLAG_IS_DEFAULT(EagerJVMCI) && !EagerJVMCI) { | ||
| FLAG_SET_DEFAULT(EagerJVMCI, true); | ||
| } |
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.
The default value is false - I don't think you need check it.
You can use FLAG_SET_ERGO_IF_DEFAULT(EagerJVMCI, true);
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
|
@dougxc please remind me. Is it true that with current libgraal no Java code is executed when it is initialized? Or you still have calls into core library? |
There are still some calls to |
|
Thanks for the reviews! /integrate |
|
Going to push as commit 08b2df8.
Your commit was automatically rebased without conflicts. |
By default, JVMCI and Graal initialization only occurs on the first top-tier (i.e. tier 4) JIT compilation request. This made sense prior to libgraal where the initialization was interpreted and so noticeably contributed to VM startup. However, with libgraal, the initialization is sufficiently fast to not impact startup.
The motivation for JVMCI and Graal eager initialization by default is to make Graal command line option processing happen in the same VM phase as handling of all other VM command line flags. That is, errors in Graal options should:
java -XX:+UnlockExperimentalVMOptions -XX:+UseGraalJIT --version. In a JDK build that does not include Graal, this may succeed (and print out the version info) or result in a VM error ("Cannot use JVMCI compiler: No JVMCI compiler found").This PR makes JVMCI initialization eager by default if
UseJVMCICompileris true.This is done for both libgraal and jargraal so that the behavior is uniform. Since jargraal is now a development configuration, VM startup costs are not critical.
Progress
Issue
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/25121/head:pull/25121$ git checkout pull/25121Update a local copy of the PR:
$ git checkout pull/25121$ git pull https://git.openjdk.org/jdk.git pull/25121/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 25121View PR using the GUI difftool:
$ git pr show -t 25121Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/25121.diff
Using Webrev
Link to Webrev Comment