Does anyone know what triggers KGP to spawn a new ...

# gradle

[tony]

Does anyone know what triggers KGP to spawn a new kotlin compiler daemon? I can get two to spawn reliably with these steps in a real project that has about 600 modules (Android and JVM, all Kotlin. No KMP)
1. ./gradlew app:assembleDebug (to fill up the local build cache)
2. killall -9 java
3. rm -rf app/build/ && rm -rf app-old/build/
4. ./gradlew app:assembleDebug --no-build-cache
I observe a compiler daemon spawn when app-old:compileDebugKotlin starts, and a second daemon starts when app:compileDebugKotlin starts. I think it's that app-old is so large. Sort of a "hairball" module that's being actively modularized as I write this. My working hypothesis is that it's a resource constraint. Using daemonitor-cli, I can see the original compiler daemon reach CRIT MEM while compiling app-old (it is far below it's Xmx value, though). I can't rule out that there's something difference between those two modules that triggers this. The two daemons have essentially identical JVM args

[tony]

the only difference is this value

-Dkotlin.daemon.initiator.marker.file=/var/folders/gc/72bxcq0j7rgfvd7wfx7tbxxw0000gn/T/kotlin-compiler-client-9620956159641280546-is-running

[tony]

ok, figured it out, I think. We had this in just the app module:

configurations
  .matching { it.name != "detekt" }
  .configureEach {
    resolutionStrategy.eachDependency {
      if (requested.group == "org.jetbrains.kotlin") {
        useVersion(libs.versions.jetbrains.kotlin.library.get())
      }
    }
  }

and this also configured the kotlinBuildToolsApiClasspath configuration (again, just in app). In particular, just app had kotlin-reflect 2.4.21 on that classpath, while everywhere else had kotlin-reflect at 1.6.10. So I think it's the changing classpath causing a new daemon to spawn when app gets compiled.

Very weird that kotlin-reflect 1.6.10 is still hanging around everywhere. Reminds me of the issue that led to me writing this blog post