https://kotlinlang.org logo
Join Slack
Powered by
I raised the Xmx on my `kotlin.daemon.jvm.options`...
# gradle
e
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:
Copy code
Could not connect to Kotlin compile daemon
Could not connect to kotlin daemon. Using fallback strategy.
t
12g
is quite high for Kotlin daemon 🤔 How many modules your project has?
e
~150
We made it that high to match the Gradle daemon JVM args. We're using 
12g
because Android lint is very memory hungry.
t
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?
and also you could vote for KT-31602
e
We're only using 
12g
on our CI machine for jobs that use lint, and that's where we experience the issue.
This is the full command we run:
Copy code
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
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.
Although that may be an artifact of how lint works, I'm not sure.
😑 
The build scan publishing request was rejected as the data exceeded the maximum size.
 Wrong thread
t
Imho, you should not have such many Kotlin processes running - if you compare command line of Kotlin daemons (
jps -v
) - are they the same? 🤔
a
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
t
1.5.30
release will have better ways to provide jvm args to daemon
e
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?
t
it is specific to kotlin daemon options
👍 1
@dsvoronin could test an assumption that limiting workers count in the build lowers probability of Kotlin daemon not available?
d
yep, i decreased it to 4 from default 32; still reproducible if it's about 
org.gradle.workers.max
yes black 1
t
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?
and just to be sure - Kotlin version is 1.5.30?
d
1.5.21; we have problems with buildscript classpath, overriding it to 1.5.30 on top of embedded in gradle
🤔 1
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
t
Could you also create an issue regarding adding the flag for the daemon fallback strategy?
d
Yep, will do
🙏 1
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
t
probably, when flag is enabled, we could also output path to the failed daemon log file
d
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
👌 1
508 Views
Open in Slack
PreviousNext
Powered by