[GRADLE-1771] Tooling API should start daemon with -client option (or at least provide a way to control options passed to daemon process) Created: 29/Aug/11 Updated: 04/Jan/13 Resolved: 16/Mar/12 |
|
Status: | Resolved |
Project: | Gradle |
Affects Version/s: | None |
Fix Version/s: | 1.0-milestone-9 |
Type: | Improvement | ||
Reporter: | Kris De Volder | Assignee: | Szczepan Faber |
Resolution: | Fixed | Votes: | 2 |
Description |
Since I upgraded not to long ago to a new version of Java on Ubuntu. It looks like the JVM on my particular configuration now defaults to running in Server mode whereas previously that used to be client mode. The main problem I have with that is that it makes the Gradle daemon consume considerably more memory which causes my machine to start using the swap memory and paging. That is quite annoying. What I observe when running Gradle STS tests on my machine is that memory usage of my machine which runs 32 bit OS and JVM and has 4Gb of RAM goes from around 20% (includes one STS instance running) before starting the tests to fully utilizing all memory and just starting to spill over into swap. This includes two instances of Eclipse STS and two daemons spawned for running two different version of Gradle (M3 and M4). After the tests exit one of the STS instances (the one executing the tests) goes away but the daemons remain active. Leaving my memory consumption around 80%. Most of this memory seems to be going to the two daemon processes. (Though the STS's are probably heavier processes, I am running the STS's with -client which seems to be much friendlier towards memory usage). There seems to be no way for me to control this option (or any other ones?), for the daemon process spawned by the tooling API so I am guessing they are running in "server" mode. Though this may be rather specific to a user's machine, JVM version etc. I suggest adding the -client option as a default may be a good idea. If not, at least it should be able for a tooling API client to control the setting of this option (and possible other JVM options) that are passed to the daemon process. This is major issue to me, because it makes my machine rather unpleasant to use. |
Comments |
Comment by Szczepan Faber [ 01/Sep/11 ] |
We may fix it along with |
Comment by Kris De Volder [ 01/Sep/11 ] |
Sounds good. But I consider this a separate issue since the tooling API, as far as I know doesn't provide a way to set environment parameters or really any kind of parameters or system properties passed to the daemon process. The API should provide its own mechanism to set options and not rely on os environment parameters. |
Comment by Davide Cavestro [ 20/Sep/11 ] |
I agree with Kris: please improve the tooling API, otherwise IDE integration may result cumbersome... |
Comment by Szczepan Faber [ 16/Mar/12 ] |
If that's ok I'm closing this issue. The tooling api now provides a way of specifying the jvm options that are later used to kick off the daemon. |
Comment by Kris De Volder [ 16/Mar/12 ] |
Sure that is great. Now it is up to me to create some preferences stuff in STS-Gradle support so user's can set those options as well |