URGENT: GWT build crash with out of memory

[viny...@gmail.com]

Hi,

We are having a quite big project, every thing was going in control but from last few days our GWT project is crashing while building WAR (with error out of memory).

"Compiling module project2.Project2

   Validating units:
      Ignored 12 units with compilation errors in first pass.
Compile with -strict or with -logLevel set to TRACE or DEBUG to see all errors.
   Compiling 1 permutation

      Compiling permutation 0...

[ERROR] OutOfMemoryError: Increase heap size or lower gwt.jjs.maxThreads
java.lang.OutOfMemoryError: Java heap space"

System  (PC) configuration on which we are building WAR is:

OS = WINDOWS SERVER 2019

PROCESSOR = XEON (R) CPU E3-1225 V5 @ 3.3Ghz

CORE = 4

RAM = 64GB

HARD DISK = HDD 

C (OS drive) =  203GB free of 243GB

E (drive) =  501GB free of 642GB

F (drive) =  467GB free of 976GB

rest please find the PC images attached.

GWT build configuration is: 

gwt.module=project1.Project1 project2.Project2
gwt.output.dir=/org.yournamehere.Main
gwt.compiler.output.style=OBFUSCATED
gwt.compiler.jvmargs=-Xmx61440m
gwt.compiler.local.workers=1
gwt.compiler.logLevel=INFO
gwt.shell.output.style=OBFUSCATED
gwt.shell.logLevel=TRACE

gwt.shell.jvmargs=-Xmx61440m
gwt.shell.java=
gwt.version=2.6
gwt.shell.code.server.port=9997
gwt.shell.port=8888

rest please find the  gwt.properties file attached.

WAR file info:

*.WAR (Size on disk) = 577MB

project1.Project1

*.gwt.rpc  (count) =  1

*.gwt.rpc (size) =  8kb

*.cache.html (size) = 335kb

*.nocache.js = 6kb

project2.Project2

*.gwt.rpc  (count) =  876

*.gwt.rpc (size) =  9.76MB

*.gwt.rpc (max) = 19kb - 11kb (158 files), 10kb - 8kb (718 files)

*.cache.html (size) = 1713kb

*.nocache.js = 6kb

deferredjs\4D7A0074D70FA749A45BC16CDEAAFFE3\*.cache.js (count) = 856

deferredjs\4D7A0074D70FA749A45BC16CDEAAFFE3\*.cache.js (size) = 28.6MB

deferredjs\4D7A0074D70FA749A45BC16CDEAAFFE3\*.cache.js (max) = 4043kb(1 file), 446kb - 101kb (38 files), 98kb - 1kb (817 files). 

WE REQUEST TO ALL PLEASE HELP! AS DELIVERY OF THE WAR IS REQUIRED ON URGENT BASIS.

[vie...@gmail.com]

Hi there,

you can check, if there are the correct values with jconsole or visualvm. Please check the java call you are using to build the project. Maybe you can add there a general -Xmx4000M (or something).

Best regards

[Frank Hossfeld]

First, you should fix this:

ompiling module project2.Project2

   Validating units:
      Ignored 12 units with compilation errors in first pass.
Compile with -strict or with -logLevel set to TRACE or DEBUG to see all errors.

set the logLevel to TRACE and check the error message. That should point you to your problems.

[Jens]

As already said the first thing you should do is to use -strict. This makes sure GWT compiler does not ignore compile errors. Given you have 12 compile errors, you want to fix them first.

Next it looks like you have a lot of split points if you have 856 *.cache.js files. Given that 817 of these files are less than 100kb and these files are usually gzipped by the web server before transferring to the client browser, you should try to reduce the amount of split points. I could imagine that analyzing the code for split point calculation might be the culprit.

There is also an -optimize option for the GWT compiler with values 0 - 9 (0 = no optimizations, 9 = aggressive). I don't recall the default value but if it is 9 then it will do an optimize loop on the code AST until the AST does not change anymore. In rare cases this can end up in an endless loop. Using -optimize 8 usually fixes the issue as the compiler will do at most 8 optimize loops then. So you might want to try that as well.

I have a compiled app that is roughly half the size of yours (about 15 MB) and it compiles fine with just 8 GB Ram. But it only has about 20 split points.  Using 64GB seems overkill in your case. Maybe you could also try making a heap dump and analyze it in Eclipse memory analyzer to see what is consuming all your heap memory. However analyzing a 64GB heap dump won't be fun either.

-- J.

viny...@gmail.com schrieb am Dienstag, 1. März 2022 um 16:27:41 UTC+1:

[viny...@gmail.com]

First of all we are very-very thankful to VIE, FRANK & JENS for their valuable suggestions and are sorry for late reply. As we were busy in applying the solutions suggested by you people.

AS THE RESULT:-

1. As we have already using "gwt.compiler.jvmargs=-Xmx61440m" so we could not get what VIE mean to say.

2. As per the suggestion of FRANK we change the logLevel and got the error details and found that some server side classes has been used eg:

     "Line 18: No source code is available for type java.util.regex.Pattern; did you forget to inherit a required module?"

      We solved the bugs one-by-one BUT this also not resolved our primary problem. 

3. As per the suggestion of JENS

     3.1. We used  -optimize BUT this also not resolved our primary problem. 

     3.2. We tried to lower down the split points by 100. As we get near to 756 *.cache.js files. The code started to compile in 35-40 minutes. 

               So! the split points were the culprit.

Now our war file is compiling in 30-40 minutes and we are planning to lower down the split points more.

WE ARE VERY THANKFULL TO ALL OF YOU. AS YOUR VALUABLE SUGGESTION HAD SAVED US.

[Colin Alworth]

Split points are amazingly expensive to compute (in both CPU and memory) - I would definitely remove all split points currently under 10KB, and strongly consider removing all under 100KB, at least for an application of that size. Odds are excellent that your 4043KB file is your "leftovers" split point (you can confirm this by checking if the name of the file is the largest number in that directory) - if so, it is quite possible that removing other tiny split points will decrease the size of the leftovers and increase the size of the other larger split points. It may increase the initial download size as well, which could tell you that it could be wise to carefully put some back, but taking care to merge related split points (for example, using GWT.runAsync(Class, RunAsyncCallback) to tell the compiler that more than one RunAsyncCallback should be merged as the main file).

Consider the order that your files must load in order for the application to start up - first, the 1.7MB file loads, and the app is usable until the first split point loads. Does that first split point load instantly? Does more than one load right away before the app can be used? Consider merging those split points, or entirely removing them, if they don't provide some concrete benefit (like allowing the user to start logging in while the rest of the app is still downloading, etc).

Next, before the very first split point can be loaded, the "leftovers" split point is loaded - the split point with the biggest number, in your case this would be 756.cache.js (as of your last message). This must be downloaded and run before any other split point can be loaded - if this is your biggest one by a factor of of almost 10, it might not even make sense to have more than a handful of split points, unless you can find a way to bring that leftover size down, or possible merge it into the initial split point.

[Leon Pennings]

tbh, I've never worked with split points before. 

What would be the actual problem be if splitpoints are not used - besides from the initial load times?

Op vrijdag 1 april 2022 om 17:46:40 UTC+2 schreef nilo...@gmail.com:

[Craig Mitchell]

That's the only reason I use split points, to speed up load times.  I split the admin pages, from the public pages, so the public don't need to d/l all the admin JS.