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!

[Colin Alworth]

I've sent you an email off-list to discuss times for a call.

There are a number of other questions in my last message that would be helpful to answer, though I can at least say this much:

 * With only one <hash>.cache.js, there is only one module (i.e. .gwt.xml file) being compiled, the other files must be to partition the project in some way. There is also then only one permutation, all the others must either be collapsed through settings in those .gwt.xml files, or through the -setProperty  passed to the compiler.

 * 1.5k split points is _a lot_. Almost certainly you are spending far more memory and time to compile them than you are getting benefit out of them - even without the SOYC report, you should be able to quickly decide how many of them are worth keeping by their size, and then track down where they come from and remove most of them. There are automated options to give the compiler discretion on which split points to remove as well, but a better option is to outright remove the useless ones and save your users extra load time for tiny files, and save yourself compile time. A quick grouping of these files by size would help to understand which ones bring benefit and which don't.

 * In draft mode, split points _should_ be disabled, so this also brings to mind the question of "how are you compiling for prod mode" - how much memory and time does it take to produce those 1.5k split points? From there, hopefully we can disable split points and work towards a usable command for quick local builds.