Thursday, March 14, 2019

Re: GWT Compilation Out Of Memory

How much Java code goes into this? Combined file, line counts between shared and client packages?

From your .gwt.rpc files, My guess is that you have a huge amount of duplication between RPC interfaces. Improper use of supertypes, generics, interfaces, etc can cause the compiler to believe that much more is necessary to be compiled into each individual RPC service than actually is there. While people tend to suspect that List or Map or Set can cause this problem (and they can, if you subclass those yourself, but stock GWT plus guava doesn't actually have all that many collection types...), this is usually instead actually from a project's own interfaces or superclasses. For example, it is common to make a MyCompanyDTO or something, and to reference it like `List<MyCompanyDTO>` here and there in the project. If that has hundreds or thousands of subtypes, each of those subtypes must be compiled in to every single rpc type, which multiplied by 647 is clearly a huge amount of code to generate, but usually any time this happens only a few possible subtypes even make sense there. More detail on what overlay exists between those files will help to clarify the issue.

What is the size of the _last_ file in each deferredjs/<some-giant-hash>/ directory? There will be 5 such directories, and these are the split points, except the very last file, which is the "leftovers". If the last numbered file is very large compared to the other, this points to misuse of split points, since that file is downloaded _before_ any other split point can even begin in the project, which is certainly not helpful in breaking up a large application.

Given that this is about 100mb of code per browser permutation, and given that the sum of the RPC files is far larger than that, you almost certainly have a massive amount of RPC duplication - fixing this will decrease your total compiled size and probably reduce the work the compiler needs to do by at least some small degree. With that understood and resolved, I would then just attach a normal JVM profiler to see what sort of work the compiler is up to, and see if there is something specific to your project (pathological case of some general Generator? some custom Generator poorly implemented?) that could directly be improved.

Turning off browser permutations would probably tell a lot too depending on what that does to compile times - is most of the time spent working on generating those permutations? How much of a hit to compiled sizes do you take in that process? etc.

It might also be helpful to know if there is anything else on this system causing it to be slow, like some antivirus trying to scan while the compiler runs and generates new code. Lacking other detail from these questions, 8 hours sounds at least 7 hours too long to me on modern hardware. That processor looks to be about 3 years old from a quick search, but I'd expect that it should still be more than enough for this job.

On Thursday, March 14, 2019 at 5:21:13 AM UTC-5, Vineet Jaiswal wrote:
1. is there any relation between split points & *.cache.html files.
2. what should be the supposed ideal time of compilation for my application. as I have mentioned the size of war generated after compilation & keeping the system configuration in mind.

folders & files size generated in war files are as follows:
  1. deferredjs folder contains 5 folders (441mb of js files cumulative)  
  2. *.gwt.rpc 647 files (308mb cumulative)
  3. *.cache.html 5 files (27.9mb cumulative)
  4. *.nocache.js is 8kb
  5. and other folders

On Thursday, March 14, 2019 at 3:33:18 PM UTC+5:30, Vineet Jaiswal wrote:

GWT version: 2.6.1
Browser (with version): any
Operating System: Windows

My Application is producing 1.6GB of war file and taking 7 to 8 hrs. for complete build of 5 permutation.
configuration of machine on which we are compiling is:
OS: windows server 2012 R2
Processor: Intel R ZEON R CPU E3-1225 V5
Core : 4

we have defined gwt compile parameters as follows:
GWT Compiler JVM Arguments: -Xmx61440M
GWT Dev Mode JVM Arguments: -Xmx61440M
GWT Test JVM Arguments: -Xmx61440M

we are facing two major problems:

  1. from last few days we are receiving out of memory error during compilation.
  2. it is taking very huge time to build.

we wish our project could break into smaller sections (modules compiled individually separately) and bundled in a single war at the time of release. like we use multiple dlls and use it in single exe. and in case of changes in any dll we need not to build whole exe again instead we only compile a dll and deploy it to client.

any suggestion \ help will be highly appreciated.

thank you!

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
To post to this group, send email to
Visit this group at
For more options, visit

No comments:

Post a Comment