I raised the Xmx on my `kotlin.daemon.jvm.options` to 12g and now I'm intermittently getting this wa...

# gradle

[eygraber]

I raised the Xmx on my kotlin.daemon.jvm.options to 12g and now I'm intermittently getting this warning multiple times in my builds (and my builds are going apprx 3-4x slower). The build still completes successfully:

Could not connect to Kotlin compile daemon
Could not connect to kotlin daemon. Using fallback strategy.

[tapchicoma]

12g is quite high for Kotlin daemon 🤔

How many modules your project has?

[eygraber]

~150

[eygraber]

We made it that high to match the Gradle daemon JVM args. We're using 12g because Android lint is very memory hungry.

[tapchicoma]

this could slow down you builds when you are not running lint as Gradle/Kotlin daemon will spend much time on GC. Probably you could set such high Xmx only when you are running lint task.

Do you such log on your CI or also when developing locally?

[tapchicoma]

and also you could vote for KT-31602

[eygraber]

We're only using 12g on our CI machine for jobs that use lint, and that's where we experience the issue.

[eygraber]

This is the full command we run:

gradle -Dorg.gradle.jvmargs="-Xmx12g -XX:ReservedCodeCacheSize=240m -XX:+UseCompressedOops -XX:+UseParallelGC -XX:MetaspaceSize=256m -Dfile.encoding=UTF-8"     -Dkotlin.daemon.jvm.options="-Xmx12g -XX:ReservedCodeCacheSize=240m -XX:+UseCompressedOops -XX:+UseParallelGC -XX:MetaspaceSize=256m -Dfile.encoding=UTF-8"     :app:lintDevRelease testDevRelease -Pkotlin.incremental=false --scan --no-daemon

[eygraber]

Maybe it's related to https://issuetracker.google.com/issues/191276587#comment3?

I just tried running that command on my local machine (testing something unrelated) and I started getting those messages about not being able to connect to the compile daemon. When I checked my running processes, there were apprx 10 kotlin compile daemon processes running.

[eygraber]

Although that may be an artifact of how lint works, I'm not sure.

[eygraber]

😑

The build scan publishing request was rejected as the data exceeded the maximum size.

Wrong thread

[tapchicoma]

Imho, you should not have such many Kotlin processes running - if you compare command line of Kotlin daemons (jps -v) - are they the same? 🤔

[Alexander.Likhachev]

You should pass multiple arguments to kotlin.daemon.jvm.options as comma-separated list, not whitespace-separated. It should be clarified in docs but at the moment it isn’t

[tapchicoma]

1.5.30 release will have better ways to provide jvm args to daemon

[eygraber]

So it should be -Xmx12g, -XX:ReservedCodeCaheSize=240M, -XX:UseCompressedOops, ...

Is this specific to kotlin.daemon.jvm.options or does org.gradle.jvmargs also need to be comma separated?

[tapchicoma]

it is specific to kotlin daemon options

[tapchicoma]

@dsvoronin could test an assumption that limiting workers count in the build lowers probability of Kotlin daemon not available?

[dsvoronin]

yep, i decreased it to 4 from default 32; still reproducible
if it's about org.gradle.workers.max

[tapchicoma]

Kotlin daemon writes logs to the system temp folder (on Linux it is /tmp) - could you check the logs for reasons why it may die?

[tapchicoma]

and just to be sure - Kotlin version is 1.5.30?

[dsvoronin]

1.5.21; we have problems with buildscript classpath, overriding it to 1.5.30 on top of embedded in gradle

[dsvoronin]

Only valuable additional info i could imagine is that we started to use included builds more lately; like build-logic/build-logic-settings
project is here: https://github.com/avito-tech/avito-android

[tapchicoma]

Could you also create an issue regarding adding the flag for the daemon fallback strategy?

[dsvoronin]

Yep, will do

[dsvoronin]

I will check logs more; already did, but seems like i see logs from fallback daemons; fairly low lines count and no errors
it's hard to find broken one, when dozens of them started

[tapchicoma]

probably, when flag is enabled, we could also output path to the failed daemon log file

[dsvoronin]

https://youtrack.jetbrains.com/issue/KT-48843
@tapchicoma i need your guidance: it's probably not a bug and it needs some subsystem ; i can't change it