https://gradle.com/ logo
Join Slack
Powered by
ive noticed consistently that Android studio leaks...
# community-support
a
ive noticed consistently that Android studio leaks gradle daemons pretty often, nearly daily. I typically have to kill daemons or restart the IDE then kill the daemon to get rid of leaked ones. Is this a known issue? its especially egregious since we need 24GB+ of ram to build our app in reasonable amount of time. so end up with a "BUSY" daemon thats not actually compiling, then Android studio / gradle spins up a new daemon that causes memory pressure with the other one until i kill and sometimes need to restart the IDE
m
I have this:
Copy code
$ cat ~/.gradle/gradle.properties
# 30 seconds timeout for Gradle daemons
org.gradle.daemon.idletimeout=30000
You might want to set a higher value if you are working in a single project but the default is far too high IMO
Not sure why you would have 2 if you're doing everything in AS but it's easy to spin extra daemons if you're not ultra cautious.
v
Well, the default is high to increase probability of reuse and if the daemons see there is a memory shortage on the OS they should anways end themselves earlier if they are idle.
m
if the daemons see there is a memory shortage on the OS they should anways end themselves earlier if they are idle
Is there code to do this?
My memory pressure is much much better since I cut the timeout
v
Is there code to do this?
No, pure magic 😄
Of course there is code to do it 🙂
Or I hallucinated 🙂
m
How do you detect the memory pressure on macOS (or even linux ?)
v
platforms/core-runtime/launcher/src/main/java/org/gradle/launcher/daemon/server/health/LowMemoryDaemonExpirationStrategy.java
👍 1
How do you detect the memory pressure on macOS (or even linux ?)
Why should it be different from Windows?
m
I didn't say it was different, it's just the OS I work with so it's easier for me to understand and test OSX
v
No idea, didn't read that part of the code, maybe it is in the native component, maybe there is an MBean that works everywhere, no idea 😄
m
It's using posix mach
👌 1
Don't have time to dig into this but I wouldn't be suprised there are edge cases. Last time I dug into this, a long time ago, I was amazed how hard it is to get a simple value such as "memory pressure" when you take into account swap, buffered IO pages, overcommit, mmap, etc...
In all cases, changing my timeout helped a lot and I don't think it's just a placebo effect
👌 1
a
ooo ill try the timeout. thanks I think that is quiite reasonable. im happy to eat the few second startup rather than ever encounter double daemon, which causes build speeds to slow down by 200-300%
👌 1
😆 Android studio keeps realiving the daemon
m
moe barney meme
r
I am going to divert a bit from the original topic but something catch my attention... > BTW, can't wait for https://openjdk.org/jeps/8359211 @Martin are you using G1 for android gradle builds? Android still recommends using the parallel one. I wonder if you are getting some performance improvements by using G1. Last time we benchmarked (4 years ago) we got better results with ParallelGC, but never tried again. Not sure if by now G1 will outperform...
m
Not really, I haven't changed GC. I'm just hoping G1 will fix all my problems all at once ^^
👍 1
r
hahaha, ok, thanks for the clarification!
m
sorry, I wish I had more details. Right now throwing more RAM at my processes is cheaper than proper benchmarking 😅
😅 1
j
How do you detect the memory pressure on macOS (or even linux ?)
It's indeed not that simple and slightly off-topic but I recommend this excellent talk to understand some of the issues on Linux: https://meetings-archive.debian.net/pub/debian-meetings/2025/DebConf25/debconf25-130-free-as-in-bytes.av1.webm Slides: https://salsa.debian.org/debconf-team/public/share/debconf25/-/blob/7112fe7e3a537b9223af4d09cd18808c6ed10025/slides/9-free-as-in-bytes.pdf
🙏 2
3 Views
Open in Slack
PreviousNext
Powered by