I've recently started to notice that after Android builds, a process hangs around taking up 16 GB of memory. The command line shows it's org.gradle.launcher.daemon.bootstrap.GradleDaemon. I have to kill it manually to free up memory for things like other builds.

Is there a way to not have this hang around, either at all (preferably), or at least using (much) less memory?

The priority flag is not set for this bug.
:nalexander, could you have a look please?

For more information, please visit auto_nag documentation.

(In reply to Botond Ballo [:botond] from comment #0)

I've recently started to notice that after Android builds, a process hangs around taking up 16 GB of memory. The command line shows it's org.gradle.launcher.daemon.bootstrap.GradleDaemon. I have to kill it manually to free up memory for things like other builds.

Is there a way to not have this hang around, either at all (preferably), or at least using (much) less memory?

Yes, you can disable the Gradle daemon entirely. Everything should work but be a little bit slower. (We disable the daemon entirely in automation, so this definitely works.). The daemon is supposed to die after some period of time, but it appears that it can get wedged.

For most people, the daemon is a good thing: it's shared with AS, AFAIK, and makes everything a little more responsive, so P5: I'd happily take a patch to make this configurable or more robust but won't work on it (or get anybody else to work on it).

I guess what I'm wondering about is: is it normal for the daemon to use this much memory (16 GB)?

(In reply to Botond Ballo [:botond] from comment #3)

I guess what I'm wondering about is: is it normal for the daemon to use this much memory (16 GB)?

I don't think so, but I don't really know. The daemon services multiple projects and potentially multiple versions of things (IIUC); so it's difficult to know what might be going on. But if you only build m-c/GV, and no other projects, then no, that seems much higher than I expect. We do allow very large JVM heaps so if you got a few JVMs hanging around we might see problems.

So, I guess a little more information on your usage might help, but I really don't see this as a priority: there are multiple workarounds available and memory starvation doesn't seem to be a widespread or significant issue for Gecko developers at this time.

For the next person here: you can stop the Gradle daemon with:

./gradlew --help
...
--stop                             Stops the Gradle daemon if it is running.