Enable G1 for Bazel and the Java host toolchain. #8423
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
3842bd3 disabled G1 for Bazel itself as well as the javac workers. At that time, Bazel was using an embedded JDK 9. Now, Bazel uses Java 11, so it's worth reconsidering the choice. In particular, the introduction of parallel full G1 GC in Java 10 addressed G1 throughput issues. I tried to replicate the benchmarks mentioned by 3842bd3 and couldn't see any difference between G1 and the Old Parallel GC. (3842bd3 is not clear about the experimental protocol. My approach was to do an initial build of the target and then run "clean" between each measurement.) Additionally, on my machine, java8 and java11 startup times are within 10ms of each other. Further in G1's favor is some internal experience. We have targets that either OOM or fall into the slow full gc death march with the Old Parallel GC but do fine under G1.
|
@meisterT can you please run some benchmarks with thsi change? |
|
Thanks, I had the same change on my TODO list. I will do some performance measurements end of this week. |
|
I did a bunch of measurements and couldn't find any significant improvement or regression from this change on small projects. We did tests with Blaze on larger projects and have seen the same behavior as Benjamin describes in the initial post. We also slowly get bazel-nightly pipeline in place, so I'll import this change and see if there's any noticeable difference on any of the tested platforms. |
siberex
pushed a commit
to siberex/bazel
that referenced
this pull request
Jul 4, 2019
3842bd3 disabled G1 for Bazel itself as well as the javac workers. At that time, Bazel was using an embedded JDK 9. Now, Bazel uses Java 11, so it's worth reconsidering the choice. In particular, the introduction of parallel full G1 GC in Java 10 addressed G1 throughput issues. I tried to replicate the benchmarks mentioned by 3842bd3 and couldn't see any difference between G1 and the Old Parallel GC. (3842bd3 is not clear about the experimental protocol. My approach was to do an initial build of the target and then run "clean" between each measurement.) Additionally, on my machine, java8 and java11 startup times are within 10ms of each other. Further in G1's favor is some internal experience. We have targets that either OOM or fall into the slow full gc death march with the Old Parallel GC but do fine under G1. Closes bazelbuild#8423. PiperOrigin-RevId: 256334384
irengrig
pushed a commit
to irengrig/bazel
that referenced
this pull request
Jul 15, 2019
3842bd3 disabled G1 for Bazel itself as well as the javac workers. At that time, Bazel was using an embedded JDK 9. Now, Bazel uses Java 11, so it's worth reconsidering the choice. In particular, the introduction of parallel full G1 GC in Java 10 addressed G1 throughput issues. I tried to replicate the benchmarks mentioned by 3842bd3 and couldn't see any difference between G1 and the Old Parallel GC. (3842bd3 is not clear about the experimental protocol. My approach was to do an initial build of the target and then run "clean" between each measurement.) Additionally, on my machine, java8 and java11 startup times are within 10ms of each other. Further in G1's favor is some internal experience. We have targets that either OOM or fall into the slow full gc death march with the Old Parallel GC but do fine under G1. Closes bazelbuild#8423. PiperOrigin-RevId: 256334384
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
3842bd3 disabled G1 for Bazel itself as well as the javac workers. At that time, Bazel was using an embedded JDK 9. Now, Bazel uses Java 11, so it's worth reconsidering the choice. In particular, the introduction of parallel full G1 GC in Java 10 addressed G1 throughput issues.
I tried to replicate the benchmarks mentioned by 3842bd3 and couldn't see any difference between G1 and the Old Parallel GC. (3842bd3 is not clear about the experimental protocol. My approach was to do an initial build of the target and then run "clean" between each measurement.) Additionally, on my machine, java8 and java11 startup times are within 10ms of each other.
Further in G1's favor is some internal experience. We have targets that either OOM or fall into the slow full gc death march with the Old Parallel GC but do fine under G1.