Will print mem usage
Compiling module XXX
[CompStateBuilt] 320804120 heap, 21314504 nonheap, 342118624 total, 23.21s
[AstOnly] 604512808 heap, 42120632 nonheap, 646633440 total, 38.71s
Compiling 6 permutations
Compiling permutation 0...
[makeSoycArtifactsS] 754570192 heap, 50642360 nonheap, 805212552 total, 103.22s
Compiling permutation 1...
[makeSoycArtifactsS] 737860952 heap, 51196480 nonheap, 789057432 total, 55.79s
Compiling permutation 2...
[makeSoycArtifactsS] 737125848 heap, 51479208 nonheap, 788605056 total, 56.86s
Compiling permutation 3...
[makeSoycArtifactsS] 736970808 heap, 51584272 nonheap, 788555080 total, 57.11s
Compiling permutation 4...
[makeSoycArtifactsS] 737455120 heap, 51679488 nonheap, 789134608 total, 55.08s
Compiling permutation 5...
[makeSoycArtifactsS] 737228448 heap, 51688424 nonheap, 788916872 total, 54.64s
Compile of permutations succeeded
Linking into xxxxxxx
Compilation succeeded -- 498.726s
As you can see, the graph is different when run with the -Dgwt.memory.usage option. When this argument is specified, at the end of each permutation System.gc() gets called 4 times by com.google.gwt.dev.util.Memory.maybeDumpMemory() and then prints the memory statistics in the console[makeSoycArtifactsS] . Because of these garbage collection calls, the heap size gets reduced to around 750 MB. Basically during each permutation compile, the memory goes up while building the permutation and goes to a low while printing the output.
Now, if you see the first graph, which is obtained without this option, the heap size does not come down after each permutation compile, so the overall memory required goes up for the last 2/3 permutations(There is a difference of ~450MB) .
I also looked at what is causing the memory to jump during each permutation compilation by taking a heap dump at one of the peaks and comparing it to the heapdump at the AstOnly stage. The comparison showed that most of the memory is taken up by HashMap.Entry objects which contain JMethod,JField etc.. Most of these HashMaps are referenced by com.google.gwt.dev.jjs.impl.ControlFlowAnalyzer.RescueVisitor .
I have the following questions
- Should GWT be calling System.gc() by default after each permutation compile so that the heap does not grow? (Right now it does that only with the -Dgwt.memory.usage option)
- The memory growth due to RescueVisitor, can this be due to including modules which are not required? Is there a way to find out the classes that are pruned by the compiler. Can there be any other optimization we can do to reduce this memory growth?
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to email@example.com.
To post to this group, send email to firstname.lastname@example.org.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.
Post a Comment