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.
On Wednesday, February 11, 2026 at 12:29:46 AM UTC-6 AFK wrote: > 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/4013fbce-c46d-4a3b-a45a-b7a103aa717dn%40googlegroups.com.
