It’s a 64bit debian. Well, default Java options are not low at all… At this machine, every new JVM swallows over 2GB:
$ java -XX:+PrintFlagsFinal -version | grep ‘(Initial|Max)HeapSize’
uintx InitialHeapSize
:= 134217728
{product}
uintx MaxHeapSize
:= 2147483648
{product}
Even jps: $ jps -J-XX:+PrintFlagsFinal | grep ‘(Initial|Max)HeapSize’
uintx InitialHeapSize
:= 8388608
{product}
uintx MaxHeapSize
:= 2147483648
{product}
And yes, changing the -Xmx settings do make a difference. This would mean, that at the time my groovy code gets compiled (after java), there are at least 3 JVMs? One for gradle, one for compiling java, and one for groovy (which fails to start). Is that right? Are the daemons reused for compiling code in other projects as well, or does, say, every compileJava / compileJava start a new daemon?
Is it necessary for gradle to fork? How big would you suggest Xmx is for the daemon, and for the compilers?
=====
Read below is you are interested in my findings.
The ‘problem’ is the following: this machine is what this document: http://docs.oracle.com/javase/7/docs/technotes/guides/vm/server-class.html calls a ‘server class machine’, that’s why it starts ith with the -server option on. Also, here: http://docs.oracle.com/javase/7/docs/technotes/guides/vm/gc-ergonomics.html it says, that the Xmx is set to smaller of 1/4 or 1gb of ram. At this particular machine, as shown above, it somehow uses the 1/4 (~2gb), which means: every new JVM uses -Xmx2g, no wonder that it fails at the third JVM (I also have tomcat 7 running, which also takes its share… And there are no JAVA_OPTS or whatever used. That’s very strange.
What is also strange (IMHO), is that even though initial heap is about 134m in the above case, the JVM will not start when there is no Xmx mem available. It seems it just allocated everything it can, instead of doing it only when needed.
During my searches, I found something interesting: the _JAVA_OPTIONS env variable. Check this out: $ export _JAVA_OPTIONS="-Xmx512m" $ jps -J-Xmx4g -J-XX:+PrintFlagsFinal | grep ‘(Initial|Max)HeapSize’ Picked up _JAVA_OPTIONS: -Xmx512m
uintx InitialHeapSize
:= 8388608
{product}
uintx MaxHeapSize
:= 536870912
{product}
I export it to set Xmx to 512m, and then, even though I start jps with -Xmx4g, it still uses 512. Note also the ‘Picked up _JAVA_OPTIONS’ part. This is a highly obscure, undocumented feature of HotSpot, there is very little in the net about it, but this setting forces every JVM to use no more than what it says. I wonder what other JVMs do.
It gets even more interesting: $ export JAVA_TOOL_OPTIONS="-Xmx256m" jps -J-Xmx4g -J-XX:+PrintFlagsFinal | grep ‘(Initial|Max)HeapSize’ Picked up JAVA_TOOL_OPTIONS: -Xmx256m Picked up _JAVA_OPTIONS: -Xmx512m
uintx InitialHeapSize
:= 8388608
{product}
uintx MaxHeapSize
:= 536870912
{product} Although JAVA_TOOL_OPTIONS is documented in JTVMI documentation. But _JAVA_OPTIONS still has priority.
wujek