GWT 2.8.0 OOM Error on compilation

[AFK]

Hey guys, Whenever i compile my GWT project, i get an OOM error:

Compiling module x Compiling 1 permutation [ERROR] OutOfMemoryError: Increase heap size or lower gwt.jjs.maxThreads java.lang.OutOfMemoryError: Java heap space at com.google.gwt.thirdparty.guava.common.collect.Iterables.concat(Iterables.java:495) at com.google.gwt.thirdparty.guava.common.collect.Iterables.concat(Iterables.java:434) at com.google.gwt.dev.jjs.ast.JMethod.getOverriddenMethodsIncludingSelf(JMethod.java:579) at com.google.gwt.dev.jjs.ast.JMethod.canBeReferencedExternally(JMethod.java:85) at com.google.gwt.dev.jjs.impl.ControlFlowAnalyzer$RescueVisitor.rescue(ControlFlowAnalyzer.java:626) at com.google.gwt.dev.jjs.impl.ControlFlowAnalyzer$RescueVisitor.visit(ControlFlowAnalyzer.java:371) at com.google.gwt.dev.jjs.ast.JMethodCall.traverse(JMethodCall.java:265) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:127) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:122) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:118) at com.google.gwt.dev.jjs.ast.JExpressionStatement.traverse(JExpressionStatement.java:42) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:146) at com.google.gwt.dev.jjs.ast.JVisitor.acceptWithInsertRemove(JVisitor.java:168) at com.google.gwt.dev.jjs.ast.JBlock.traverse(JBlock.java:92) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:127) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:139) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:135) at com.google.gwt.dev.jjs.ast.JMethodBody.traverse(JMethodBody.java:83) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:127) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:122) at com.google.gwt.dev.jjs.ast.JMethod.visitChildren(JMethod.java:786) at com.google.gwt.dev.jjs.ast.JMethod.traverse(JMethod.java:778) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:127) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:122) at com.google.gwt.dev.jjs.impl.ControlFlowAnalyzer$RescueVisitor.rescue(ControlFlowAnalyzer.java:618) at com.google.gwt.dev.jjs.impl.ControlFlowAnalyzer$RescueVisitor.visit(ControlFlowAnalyzer.java:371) at com.google.gwt.dev.jjs.impl.ControlFlowAnalyzer$RescueVisitor.visit(ControlFlowAnalyzer.java:478) at com.google.gwt.dev.jjs.ast.js.JsniMethodRef.traverse(JsniMethodRef.java:69) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:146) at com.google.gwt.dev.jjs.ast.JVisitor.acceptImmutable(JVisitor.java:154) at com.google.gwt.dev.jjs.ast.js.JsniMethodBody.traverse(JsniMethodBody.java:136) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:127) [ERROR] Out of memory; to increase the amount of memory, use the -Xmx flag at startup (java -Xmx128M ...) [ERROR] Unrecoverable exception, shutting down com.google.gwt.core.ext.UnableToCompleteException: (see previous log entries) at com.google.gwt.dev.ThreadedPermutationWorkerFactory$ThreadedPermutationWorker.compile(ThreadedPermutationWorkerFactory.java:56) at com.google.gwt.dev.PermutationWorkerFactory$Manager$WorkerThread.run(PermutationWorkerFactory.java:74) at java.lang.Thread.run(Thread.java:750) [ERROR] Not all permutation were compiled , completed (0/1)

my project is kinda old, using jars, and compiling in cmd.

I'm giving the compiler 36GB ram, compiling for only firefox, using draftCompile and much more, but nothing is working.

I'm also fairly new to GWT, and i'm really wondering how did the dev working on this specific project before me could compile it.

[Colin Alworth]

Without seeing the project, it'd be hard to guess, so a few quick notes:

 * ControlFlowAnalyzer is run as part of generating SOYC output, which is going to cost something and be entirely unnecessary for a dev build - arguably even inaccurate to the point of being counterproductive to even look at it (as it would be showing you why your app is so big... when you deliberately are building with draftCompile). Turn off SOYC/compileReport/etc, it doesn't make sense for this build.

 * GWT 2.8.0 is pretty old - you might not be able to update all the way to latest, but maybe a short step or two to see if it resolves something? (2.8.2, 2.9.0, etc)

 * What other details can you share - what args besides -draftCompile are you passing, and roughly how big is your application (in terms of Java LoC or JS output)? Also, can you confirm how you're running the compile, and how you are passing -Xmx36g (in case you're accidentally passing it to the build tool and not to GWT itself)?

[AFK]

java ^
-Xms10g ^
-Xmx36g ^
-Xss1024m ^
-Dgwt.jjs.maxThreads=1 ^
-XX:+UseG1GC ^
-cp "...\src;...\classes;...\gwt-user.jar;...\gwt-dev.jar;...\gwt-lib\*" ^
com.google.gwt.dev.Compiler ^
-localWorkers 1 ^
-style OBF ^
-optimize 0 ^
-draftCompile ^
-XdisableCastChecking ^
-XdisableClassMetadata ^
-setProperty locale=en ^
-war "...\GWT_TEST_OUTPUT" ^
-extra "...\GWT_EXTRA" ^
-deploy "...\GWT_DEPLOY" ^
-logLevel ERROR ^
"module" > "...\gwt-compile.log" 2>&1

here is the command i use. (using cmd on windows) 

i can see in the project almost 1.5k *.cache.js files.

also, there 34 *.gwt.xml files.

the project is using mxgraph/mxClient library

[Colin Alworth]

That seems to be a big project, but it is hard to be sure - "module", is that just a single module, and "almost 1.5k .cache.js files" is that the result of a draft compile, or a prod compile? If it is a prod compile, what settings allow that to succeed? 

How big are those files, and how are they grouped? Odds are, if this is a prod build, there are only a few (5? 10? 50?) that have a long <hashname>.cache.js, and the rest are likely to be short integer names within a deferredjs/<hashname>/ directory, indicating they are "split points", JS that isn't downloaded until it is needed. With, say, 50 permutations (browsers X locales etc), and only one single module passed to the compiler, that suggests something like 30 split points. If most of the integer named ones are small, there is likely a lot of cleanup you can do to improve compile time and load times for users.

That stack size seems ridiculously big - 1g stack is the max that the JVM supports I believe, and the default is usually less than 1mb. I don't think it should make a huge impact here, but it is surprising to see it that large, especially when the default usually works.

Beyond that, without more specifics it will be hard to make suggestions for code that used to work and now doesn't (except asking obvious questions like "what has changed since it last worked", which you might be unable to answer). I would be open to a short screensharing call to help understand more quickly how this is structured and what is happening.

[AFK]

There is only 1  <hashname>.cache.js, and almost 1.5k *.cache.js.

there's only 1 entry point module, and everything else are just sub-modules inherited. 

It would be great if we can have a quick call whenever you can. Just let me know the best time.

Thank you!