-
Notifications
You must be signed in to change notification settings - Fork 5.8k
JDK-8317987: C2 recompilations cause high memory footprint #16161
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
JDK-8317987: C2 recompilations cause high memory footprint #16161
Conversation
👋 Welcome back stuefe! A progress list of the required criteria for merging this PR into |
MacOs test error unrelated. |
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 holy grail of a 1-line fix that halves related memory footprint. Nice work!
@tstuefe 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 7 new commits pushed to the
Please see this link for an up-to-date comparison between the source branch of this pull request and the ➡️ To integrate this PR with the above commit message to the |
Yes, sometimes one still finds a free lunch :) Thanks for the review. |
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.
Nice. We added a lot of C2 recompilation cases for the past few years so it become noticeable.
The main ResourceMark
for all JIT compilers is located in CompileBroker::invoke_compiler_on_method()
: compileBroker.cpp#L2141
Going to push as commit c88b387.
Your commit was automatically rebased without conflicts. |
While playing with the new compiler memory statistic (#16076), I saw that +StressRecompile causes a twofold increase in memory used during compilations.
Baseline:
highest peak during compilation is ~60 MB, caused by compilation of
java/lang/invoke/LambdaForm$Kind::<clinit>
with ~18k nodes../images/jdk/bin/java -XX:CompileCommand='collectmemstat,*.*' -XX:-StressRecompilation -Xcomp -Xbatch -cp $REPROS_JAR de.stuefe.repros.Simple
+StressRecompile:
highest peak during compilation is ~112 MB, same method, sameish node count.
./images/jdk/bin/java -XX:CompileCommand='collectmemstat,*.*' -XX:+StressRecompilation -Xcomp -Xbatch -cp $REPROS_JAR de.stuefe.repros.Simple
60M -> 112M. In both cases, a large part of the memory was allocated in resource areas. Its relative size compared to the total spike size increased. We accrue a lot of memory in ResourceArea over recompilations.
The solution is to wrap the
Compile
instantiation into a resource mark. Now we are at 61 MB, which is almost baseline:Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/16161/head:pull/16161
$ git checkout pull/16161
Update a local copy of the PR:
$ git checkout pull/16161
$ git pull https://git.openjdk.org/jdk.git pull/16161/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 16161
View PR using the GUI difftool:
$ git pr show -t 16161
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/16161.diff
Webrev
Link to Webrev Comment