Enable G1 for Bazel and the Java host toolchain.

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 #8423.

PiperOrigin-RevId: 256334384

src/main/cpp/blaze.cc

@@ -373,9 +373,6 @@ static vector<string> GetServerExeArgs(
 
   // TODO(b/109998449): only assume JDK >= 9 for embedded JDKs
   if (!startup_options.GetEmbeddedJavabase().empty()) {
-    // In JDK9 we have seen a slow down when using the default G1 collector
-    // and thus switch back to parallel gc.
-    result.push_back("-XX:+UseParallelOldGC");
     // quiet warnings from com.google.protobuf.UnsafeUtil,
     // see: https://github.com/google/protobuf/issues/3781
     result.push_back("--add-opens=java.base/java.nio=ALL-UNNAMED");

tools/jdk/default_java_toolchain.bzl

@@ -19,10 +19,6 @@ JDK8_JVM_OPTS = [
 ]
 
 JDK9_JVM_OPTS = [
-    # In JDK9 we have seen a ~30% slow down in JavaBuilder performance when using
-    # G1 collector and having compact strings enabled.
-    "-XX:+UseParallelOldGC",
-    "-XX:-CompactStrings",
     # Allow JavaBuilder to access internal javac APIs.
     "--add-exports=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED",
     "--add-exports=jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED",