Use a ForkJoinPool for async include scanning
Previously, switching to a FJP was rolled back due to introducing a
performance regression in some cases. While I was unable to reproduce
the regression due to other changes in Bazel, this ties the switch to
the async include scanner flag. I have carefully benchmarked that, and I
think that switching to a FJP is required to roll out the async include
scanner.
PiperOrigin-RevId: 291931477
diff --git a/src/main/java/com/google/devtools/build/lib/includescanning/IncludeScanningModule.java b/src/main/java/com/google/devtools/build/lib/includescanning/IncludeScanningModule.java
index 67be91e..ade7cc2 100644
--- a/src/main/java/com/google/devtools/build/lib/includescanning/IncludeScanningModule.java
+++ b/src/main/java/com/google/devtools/build/lib/includescanning/IncludeScanningModule.java
@@ -33,6 +33,7 @@
import com.google.devtools.build.lib.analysis.BlazeDirectories;
import com.google.devtools.build.lib.buildtool.BuildRequest;
import com.google.devtools.build.lib.concurrent.ExecutorUtil;
+import com.google.devtools.build.lib.concurrent.NamedForkJoinPool;
import com.google.devtools.build.lib.concurrent.ThreadSafety.ThreadHostile;
import com.google.devtools.build.lib.exec.ExecutorBuilder;
import com.google.devtools.build.lib.exec.ExecutorLifecycleListener;
@@ -295,7 +296,11 @@
if (threads > 0) {
log.info(
String.format("Include scanning configured to use a pool with %d threads", threads));
- includePool = ExecutorUtil.newSlackPool(threads, "Include scanner");
+ if (options.useAsyncIncludeScanner) {
+ includePool = NamedForkJoinPool.newNamedPool("Include scanner", threads);
+ } else {
+ includePool = ExecutorUtil.newSlackPool(threads, "Include scanner");
+ }
} else {
log.info("Include scanning configured to use a direct executor");
includePool = MoreExecutors.newDirectExecutorService();
