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! On Wednesday, 11 February 2026 at 04:25:21 UTC+2 Colin Alworth wrote: > 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. > > On Tuesday, February 10, 2026 at 12:59:53 AM UTC-6 AFK wrote: > >> >> 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 >> On Monday, 9 February 2026 at 20:50:57 UTC+2 Colin Alworth wrote: >> >>> 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)? >>> >>> >>> >>> On Monday, February 9, 2026 at 12:32:57 PM UTC-6 AFK wrote: >>> >>>> 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. >>>> >>> -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/d09c822a-ff0e-44ce-8bf8-1e1270ac62dan%40googlegroups.com.
