Hi:
I have the same problem compiling with GWT 2.0.4. My project has about
3500 classes.
Did you find any solution?
Thanks in advance.
The JVM parameters are:
-Xss32m -Xms32m -Xmx1024m -XX:MaxPermSize=256m
The StackTrace is:
For a really large compile, you might want to supply more than 1G of memory.
I would try upping your -Xmx.
On Tue, Oct 26, 2010 at 5:37 PM, Fernando fsellecc...@gmail.com wrote:
Hi:
I have the same problem compiling with GWT 2.0.4. My project has about
3500 classes.
Did you find any
This doesn't address code-splitting per-se, but r8921 and r8850 reduce both
DevMode and compiler memory footprint.
On Sat, Sep 18, 2010 at 11:34 PM, lin.liang birdandfis...@gmail.com wrote:
Chris, I didn't see the OOME before using code splitting. In order to
reduce the application's startup
Chris, I didn't see the OOME before using code splitting. In order to
reduce the application's startup time, I adopt code splitting in the
DynaClassGenerator.java (the implementation of GWT generator on data
deferred binding in our project)
1) Before using code splitting, the code is:
if
The OutOfMemory exception always happen when the gwt project was
complied. The gwt project has 7 modules, and about 5,700 java files.
I have a look at gwt docs. It said that when the project became
bigger, the complier using the memory more too. However, I have set
the memory to 1.7G, it still
That should be more than enough memory to run your compile. Do you have a
stack trace for the OOME?
FWIW, I have a pending change that should decrease the amount of memory
needed to run a compile or DevMode.
On Fri, Sep 17, 2010 at 7:19 AM, lin.liang birdandfis...@gmail.com wrote:
The
I had this trouble but my project was very small, but my solution was to
divide my clientbundles to smaller ones. processing lots of images can
consume very much memory.
2010/9/17 Chris Conroy con...@google.com
That should be more than enough memory to run your compile. Do you have a
stack
