Wouldn’t it be good if the gradle launch would be structured in stages, where the 1st stage is a JVM process that possibly collects some data in order to properly launch the actual gradle JVM and its daemon? This way the 1st stage could: - access every kind of configuration through raw properties files, groovy (config slurper), gradle ad-hoc dsl file (in the gradle work dir or specified from CLI/env var), ini4j, java preferences api and so on (there could be an ecosystem of gradle plugins here) - launch the gradle JVM and its daemon with proper options (separate stages?)
Please note that if the 1st stage can access groovy/gradle code, we could also provide some heuristics or at least use some conditional statements in order to produce properly JVM configuration options. Granting access to well-known configuration facilities (ini4j, java preferences) would also give the opportunity to use some GUI tools to write them.
We’ve actually been discussing something like an initialisation vm for a little while. The problem we keep running into is that this will blow out startup time. We may be able to circumvent this by bootstrapping with native code, but that has its own problems.
As for pre populating the model externally, that’s also something we are conscious of.
To help scope these ideas, perhaps you could give some examples of how you would use this functionality or what you would hope to achieve with this mechanism.
Hi Luke, I essentially need to share with my team through version control proper JVM configuration flags (-Xmx, maxpermsize and so on) on a per-task fashion, being able to use them both from CLI and IDE integration (Eclipse/STS). I would avoid using shell scripts cause they are not really portable on different OSes. Our machines have similar hardware, so being able to override the configuration on a per-user basis is not really needed (nevertheless it could be useful). The JVM configuration is especially needed to control memory usage, cause we often experience scenarios where a developer should be able to run the ide (STS) with its gradle daemon, a tomcat instance (xmx768 and maxpermsize of 256m), the gwt dev mode app spawned from the ide through gradle, and from time to time other gradle tasks (gwt compiler and so on). Especially on a 64-bit arch this scenario easily lead to heavy swap a machine dedicated to development with 4GB of ram.
One option we’ve talked about, which may better solve your use case, is some way to fork tasks from the build, so that memory intensive tasks (or their actions, possibly) run in a separate jvm with its own jvm settings that you can control from the build script. We’d have some smarts in there to attempt to reuse processes, so that you avoid the process startup cost.
This way, you can have a relatively small heap specified for the build process, and still have the ability to have logic in the build script (or plugins) for controlling jvm settings on a per-task basis, for those tasks where it matters.
We plan to move all compilation to fork mode, and probably several other tasks, too. Testing already uses fork mode.
@Adam that would be great, much better than what I proposed. Do you think it could be added to the roadmap or is it on an early/brainstorming stage? Cheers