Just checked to be sure. My previous project had 18M per permutation of cache.js, no split points and an -Xmx2000m for gwt compilation. I just built the web project on my laptop and it was a 2 min build. I don't know what one would have to do to require that many mem - or even need split points. I never ran into the need for more mem/split points. But now I'm quite curious though ;-)
On Wed, Sep 25, 2024 at 10:56 PM <[email protected]> wrote: > [email protected] > <https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!forum/google-web-toolkit/topics> > Google > Groups > <https://groups.google.com/forum/?utm_source=digest&utm_medium=email/#!overview> > [image: > Google Groups Logo] > <https://groups.google.com/forum/?utm_source=digest&utm_medium=email/#!overview> > Topic digest > View all topics > <https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!forum/google-web-toolkit/topics> > > - [ERROR] OutOfMemoryError: Increase heap size or lower > gwt.jjs.maxThreads <#m_-5021352749228990149_group_thread_0> - 2 Updates > > [ERROR] OutOfMemoryError: Increase heap size or lower gwt.jjs.maxThreads > <http://groups.google.com/group/google-web-toolkit/t/1725afa08b52c0b5?utm_source=digest&utm_medium=email> > Jens <[email protected]>: Sep 25 02:40AM -0700 > > Are you using a lot of code split points? 61GB memory seems pretty high. > Someone else once posted a similar question and this person had ~100 split > points which significantly impacted compilation. The more split points you > have the more complex analysis will be in order to determine if some code > is unique to a split point. > > As comparision I have an app that produces 10MB JS in total per > permutation > and compiles fine using 4GB memory. It uses about 12 split points. > > > Colin Alworth <[email protected]>: Sep 25 06:44AM -0700 > > Agreed with Jens, definitely look at your split point usage. In the war > that you have, you have a .cache.html file that you mentioned, 4.7MB. In > that same dir, there should be a deferredjs/ directory - can you list its > contents? It should have a directory per permutation (so, just one, named > the same as your .cache.html file), and inside that, there should be some > number of .cache.js files. How many are there, and what is their size > range > (like the .gwt.rpc table you made)? > > Odds are very high that a significant number of them are quite small, and > so shouldn't be created at all, so you can either remove them from your > code (by finding their GWT.runAsync(...) calls), or use the compiler's > built-in feature to try to minimize them, `-XfragmentCount=N`. That N is > treated as a suggestion, and the compiler will create approximately that > many split points in the final output - if that number is substantially > less than the number of GWT.runAsync() calls, you probably will see a > substantial compile time and memory usage improvement. > > If most/all of the split points are small (say, under 100KB), you might > consider disabling split points entirely to skip this processing step. > There will be an increase in your initial page size, but possibly a > manageable one. > > But the most important thing when using split points is to measure impact > on the user - when you load the page, watch the Network tab in browser > tools, and see how much you are actually deferring, how many split points > are being loaded, and how big they are. Odds are pretty high that the very > last (going by file name) split point is loaded very soon after page load, > and that this file is one of the biggest if not the biggest, which itself > suggests that some work is necessary to improve your page loading > experience. That split point is the "leftover" chunk, and represents any > code shared by two or more chunks - using the -XfragmentCount feature is > very likely to reduce its size, but modeling how your page loads and > application builds is more complex than can be written in an email. > > One more simple point: consider turning off the compiler report flag if > you > aren't actively using the results, it will take extra memory, compile > time, > and disk space. It would be helpful to turn it back on periodically, but > shouldn't be necessary to keep it on all the time for all developers. This > tool assists in some of the "why are my split points the way they are" > debugging, but if the compile doesn't succeed anyway, odds are no one is > looking at it. > > Finally, GWT 2.6.1 is more than a decade old - if you're actively > developing this application, strongly consider updating. > > > > On Wednesday, September 25, 2024 at 4:40:36 AM UTC-5 Jens wrote: > > Back to top <#m_-5021352749228990149_digest_top> > You received this digest because you're subscribed to updates for this > group. You can change your settings on the group membership page > <https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!forum/google-web-toolkit/join> > . > To unsubscribe from this group and stop receiving emails from it send an > email to [email protected]. > -- 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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/CABjQu7T32ZasY27zj3VhxFSR413cqPitH8TVMeT%2BX6M9PXqUhQ%40mail.gmail.com.
