added a comment - - edited
I played with a little bit. It is hard to say for me whether this is really 'fixed'. I could only do limited testing of this since you are limiting me to use projects that work with M5 snapshot. Most of the projects that I test with, today, only work properly in M3.
However here some limited observations:
1) I managed to get two concurrent daemons started. This happened as I was trying to run two concurrent Gradle operations in two separate STS instances. Once the daemons where created they never really went away by themselves. I did wait for some time (30 minutes maybe?). But the daemons just kept sitting around idle. I noticed this "-Dorg.gradle.daemon.idletimeout=10800000" argument in the process. If it means what I think it means... it means the daemon should go away after 3 hours? If so, then it is really pretty much equivalent to 'indefinitely' in practice. The daemon should go away after 10 idle minutes tops.
If more than one daemon is concurrently started, you should even consider lowering the limit. Get that second daemon to go away immediately.
In my opinion, the negative effect of having these two big processes pushing my machine towards starting to swap, or at least reducing what I have left over for file caches, more than offset the speedup I get on the odd gradle command that I need to execute.
2) fixing the deamon management in the gradle distribution rather than on the API side, in my opinion, is a mistake. All daemons for all versions should be managed together and with something that knows how many daemons have been created, regardless of gradle version.
Indeed, a common cause (for me at least) of spawning multiple daemons is that some commands get executed with different versions.
The reason why multiple versions get used could be...
- multiple projects using different versions (maybe not common in real use, but consider that if the daemons stay around indefinitely or at least several hours, it is not that unlikely that I'd switch working on different projects in the span of 3 hours...)
- bug http://issues.gradle.org/browse/GRADLE-1765
Bug 1765 is quite bad, in combination with the poor daemon management because it tends to spawn an extra daemon which then just sits around forever (or at least a very long time).
If I had my way, I'd really never want to see more than one daemon sticking around. And even that one daemon, I'd like to go away after a much shorter time than 3 hours.
If you must start a second daemon to maintain responsiveness while the first one is busy, fine, but don't then keep both daemons around for 3 hours after that.
Also, really, daemons should be managed by something that spans gradle versions in my opinion... because you need to consider how many daemons are already active, regardless of version, to decide how long you want to keep the daemons around in idle state.
The problem with an idle daemon is that it is 'expensive' as it puts a constant drain on my resources (memory!) and really doesn't offer much benefit if it isn't being frequently used. (once every 3 hours is not really frequent, and does not warrant paying 1+Gb of memory to speed up the next command by a few seconds or even 10s of seconds).
Also, consider that if my machine is under "memory pressure" the idle daemon will mostly be paged out, and it probably will not be that 'fast' the next time I try to call on it anyway.