Hi all, I'm on the process of implementing Gradle as the build-management tool for a Grails app, but I'm facing a rather ugly issue, OOM Perm Gen. As I've acknowledged, this is most common to Groovy/Grails apps. Although, there's a known workaround: increase the MaxPermSize property for the JVM. Or even for the coding-cowboys, CMSClassUnloadingEnabled!!
The thing here is I've never had this issue while running 'grails run-app', for instance, but instead, when I run "gradle grails-run-app". Check a snippet of the output.. Running Grails application.. java.lang.OutOfMemoryError: PermGen space Server failed to start: java.lang.OutOfMemoryError: PermGen space As a workaround, I've created a bash script which will set GRADLE_OPTSwith the following contents: #!/bin/bash GRADLE_OPTS="-Xmx1024m -Xms256m -XX:MaxPermSize=512m -XX:+CMSClassUnloadingEnabled -XX:+HeapDumpOnOutOfMemoryError" gradle grails-run-app This is OK and it can even be committed to the project's SCM so that other developers may use it, but this brings me to the human factor! If you leave an open gate, then someone will cross it, even if it's surrounded by lots of big-red-blinking-signs advising you no to do so. And in this case, you leave the option of accidentally not running the script but instead call directly 'gradle grails-run-app'. Now, and as a permanent solution, it would be nice if I could set these options in 'gradle.properties'! This way, there would be much more transparency and less accidents, if any. But, correct me if I'm wrong, I believe one cannot define these memory-related variables _after_ the JVM is already running. So, it would be nice if gradle could read such properties and, for instance, spawn a new JVM/Gradle process with those memory options set, would it not?! What do you think? Is my logic wrong? Thanks in advance, Paulo Pires -- Paulo Pires
