GWT Compiler Is Running Out of Memory

as part of evaluating an open-source framework which uses google web toolkit i ran into some of the familiar issues i already had a few times earlier with the gwt (gwt 2.4 or 2.5) maven plugin compilation running out of memory. you know, when you see…

…at the start:

[info] # there is insufficient memory for the java runtime environment to continue.
[info] # native memory allocation (malloc) failed to allocate 32744 bytes for chunkpool::allocate

…or during compilation:

[info]  compiling 12 permutations
[info]  compiling permutation 1...
[info]  process output
[info]  error occurred during initialization of vm
[info]  could not reserve enough space for object heap

this post is basically a compilation of the answers found online , and a quick reminder for myself and others who are running into similar problems with the fantastic gwt compiler .

1. first of all, check if you actually need to compile everything! skip some browsers or locales – saving all kinds of permutations – if you don’t need it for development. use the tips about how to speed up the gwt compiler and gwt compilation performance . there’s also an existing faq about gwt debugging and compiling .if you have control of your machine, cut down on other running applications and processes while you’re compiling.

2. pass along some more memory

…to maven, e.g.:

maven_opts=-xms1024m -xmx1024m -xx:maxpermsize=256m

…and/or to the gwt-maven-plugin, e.g.:

<configuration>
  <extrajvmargs>-xms768m -xmx768m</extrajvmargs>
</configuration>

you’ll have to play a bit with the values, depending on the machine you’re working on and the actually available working ram.

add some permgen space, which is used when gwt compiles java into javascript. e.g.

-xx:maxpermsize=1024m

3. try lowering the number of workers to a number explicitly below your available cores/cpu’s. if this number isn’t defined explicitly, the gwt-maven-plugin will set these to the number of available cores/cpu’s. less workers = less parallellisation = less memory overhead.

<configuration>
  <extrajvmargs>-xms768m -xmx768m</extrajvmargs>
  <localworkers>3</localworkers>
</configuration>

4. try having the “workers” work in threads, instead of spawning new processes.

<configuration>
  <extrajvmargs>-xms768m -xmx768m -dgwt.jjs.permutationworkerfactory=com.google.gwt.dev.threadedpermutationworkerfactory</extrajvmargs>
  <localworkers>3</localworkers>
</configuration>

hopefully this will save someone some valuable time finding solutions. if you have other options, feel free to add them in the comments.

original article: http://tedvinke.wordpress.com/2013/03/21/gwt-compiler-is-running-out-of-memory