When I analyze a DevMode process's memory usage (e.g. using jconsole), it shows that Heap and Non-Heap (PermGen) Memory usage increases, whenever the page is reloaded.
This happens both when I run DevMode with Firefox 14, as well as Chrome 21. The difference is however, that - with Chrome, Heap and PermGen usage restores to a very low value after calling "Perform GC" - whereas in Firefox the PermGen stays at the high value, and the Heap just decreases slightly. After a number of reloads, this leads to an out of memory (Heap or PermGen, depending on which reaches the limit first). More often than not, the out of memory is not printed (which is usual for out of memory errors).
*How to reproduce the error?*
Create a simple GWT project (e.g. the one that's auto-generated by Eclipse), use Firefox, press the reload-button repeatedly (tested on OS X 10.6, but I've encountered similar memory problems on Linux amd64, too)
*Solution?*
Without knowing anything about the details of the FF plugin, it looks as if the Chrome plugin discards the ClassLoader entirely (so the PermGen space can be freed up <http://stackoverflow.com/a/148707/291741>), whereas FF probably keeps a reference to the ClassLoader somewhere (?)
*Problems when restarting DevMode*
The problem may also explain, why many people are seeing an
[ERROR] Unable to bind socket on port 9997 -- is another session active? java.net.BindException: Address already in use
That's an interesting report. We always want to garbage collect the ClassLoader when the session is over and if that doesn't happen, it's a bug. I don't know why Firefox would behave differently; the JVM side should work the same way for Firefox versus Chrome. The only thing I can think of is some difference in distributed garbage collection, but that shouldn't matter once the session ends.
Alan's not on the team anymore. I'd like to fix this, but I'm busy with other things and I don't have a good idea where to begin. If someone's handy with a memory profiler, figuring out what's preventing the classloader from being gc-ed in this case would be very useful.
On Monday, August 27, 2012 10:07:08 AM UTC-7, Chris Lercher wrote:
> When I analyze a DevMode process's memory usage (e.g. using jconsole), it > shows that Heap and Non-Heap (PermGen) Memory usage increases, whenever the > page is reloaded.
> This happens both when I run DevMode with Firefox 14, as well as Chrome > 21. The difference is however, that > - with Chrome, Heap and PermGen usage restores to a very low value after > calling "Perform GC" > - whereas in Firefox the PermGen stays at the high value, and the Heap > just decreases slightly. After a number of reloads, this leads to an out of > memory (Heap or PermGen, depending on which reaches the limit first). More > often than not, the out of memory is not printed (which is usual for out of > memory errors).
> *How to reproduce the error?*
> Create a simple GWT project (e.g. the one that's auto-generated by > Eclipse), use Firefox, press the reload-button repeatedly > (tested on OS X 10.6, but I've encountered similar memory problems on > Linux amd64, too)
> *Solution?*
> Without knowing anything about the details of the FF plugin, it looks as > if the Chrome plugin discards the ClassLoader entirely (so the PermGen > space can be freed up <http://stackoverflow.com/a/148707/291741>), > whereas FF probably keeps a reference to the ClassLoader somewhere (?)
> *Problems when restarting DevMode*
> The problem may also explain, why many people are seeing an
> [ERROR] Unable to bind socket on port 9997 -- is another session active? > java.net.BindException: Address already in use
I analyzed this a bit more (this time on Linux), and I noticed, that the number of Thread also grows: 1 thread per reload. Again, this happens only with Firefox, not with Chrome. So probably the ClassLoader references will be discarded only when the Thread terminates...
One more thing that might be interesting: When closing the entire FF instance (just closing the tab is not enough), then the threads are discarded, and Heap/PermGen space can be garbage collected.
By the way, closing the FF instance leads to the following Exception printed by the DevMode server:
10:53:21.549 [ERROR] [mymodule] Remote connection lost
com.google.gwt.dev.shell.BrowserChannel$RemoteDeathError: Remote connection lost at com.google.gwt.dev.shell.BrowserChannelServer.reactToMessages(BrowserChanne lServer.java:308) at com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChan nelServer.java:547) at com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java :364) at java.lang.Thread.run(Thread.java:662) Caused by: java.io.EOFException: null at java.io.DataInputStream.readByte(DataInputStream.java:250) at com.google.gwt.dev.shell.BrowserChannel$Message.readMessageType(BrowserChan nel.java:1100) at com.google.gwt.dev.shell.BrowserChannelServer.reactToMessages(BrowserChanne lServer.java:284) at com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChan nelServer.java:547) at com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java :364) at java.lang.Thread.run(Thread.java:662)
On Tuesday, August 28, 2012 2:07:02 AM UTC+2, Brian Slesinsky wrote:
> That's an interesting report. We always want to garbage collect the > ClassLoader when the session is over and if that doesn't happen, it's a > bug. I don't know why Firefox would behave differently; the JVM side should > work the same way for Firefox versus Chrome. The only thing I can think of > is some difference in distributed garbage collection, but that shouldn't > matter once the session ends.
> Alan's not on the team anymore. I'd like to fix this, but I'm busy with > other things and I don't have a good idea where to begin. If someone's > handy with a memory profiler, figuring out what's preventing the > classloader from being gc-ed in this case would be very useful.
On Tuesday, August 28, 2012 11:05:38 AM UTC+2, Chris Lercher wrote:
> I analyzed this a bit more (this time on Linux), and I noticed, that the > number of Thread also grows: 1 thread per reload. Again, this happens only > with Firefox, not with Chrome. So probably the ClassLoader references will > be discarded only when the Thread terminates...
> One more thing that might be interesting: When closing the entire FF > instance (just closing the tab is not enough), then the threads are > discarded, and Heap/PermGen space can be garbage collected.
> By the way, closing the FF instance leads to the following Exception > printed by the DevMode server:
> 10:53:21.549 [ERROR] [mymodule] Remote connection lost
> com.google.gwt.dev.shell.BrowserChannel$RemoteDeathError: Remote > connection lost > at > com.google.gwt.dev.shell.BrowserChannelServer.reactToMessages(BrowserChanne lServer.java:308) > at > com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChan nelServer.java:547) > at > com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java :364) > at java.lang.Thread.run(Thread.java:662) > Caused by: java.io.EOFException: null > at java.io.DataInputStream.readByte(DataInputStream.java:250) > at > com.google.gwt.dev.shell.BrowserChannel$Message.readMessageType(BrowserChan nel.java:1100) > at > com.google.gwt.dev.shell.BrowserChannelServer.reactToMessages(BrowserChanne lServer.java:284) > at > com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChan nelServer.java:547) > at > com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java :364) > at java.lang.Thread.run(Thread.java:662)
> On Tuesday, August 28, 2012 2:07:02 AM UTC+2, Brian Slesinsky wrote:
>> That's an interesting report. We always want to garbage collect the >> ClassLoader when the session is over and if that doesn't happen, it's a >> bug. I don't know why Firefox would behave differently; the JVM side should >> work the same way for Firefox versus Chrome. The only thing I can think of >> is some difference in distributed garbage collection, but that shouldn't >> matter once the session ends.
>> Alan's not on the team anymore. I'd like to fix this, but I'm busy with >> other things and I don't have a good idea where to begin. If someone's >> handy with a memory profiler, figuring out what's preventing the >> classloader from being gc-ed in this case would be very useful.
On Tue, Aug 28, 2012 at 2:15 AM, Thomas Broyer <t.bro...@gmail.com> wrote:
> In other words: it looks like the Firefox plugin doesn't send a QuitMessage
> to the DevMode, and worse, is kept alive in the background!
> On Tuesday, August 28, 2012 11:05:38 AM UTC+2, Chris Lercher wrote:
>> I analyzed this a bit more (this time on Linux), and I noticed, that the
>> number of Thread also grows: 1 thread per reload. Again, this happens only
>> with Firefox, not with Chrome. So probably the ClassLoader references will
>> be discarded only when the Thread terminates...
>> One more thing that might be interesting: When closing the entire FF
>> instance (just closing the tab is not enough), then the threads are
>> discarded, and Heap/PermGen space can be garbage collected.
>> By the way, closing the FF instance leads to the following Exception
>> printed by the DevMode server:
>> 10:53:21.549 [ERROR] [mymodule] Remote connection lost
>> com.google.gwt.dev.shell.BrowserChannel$RemoteDeathError: Remote
>> connection lost
>> at
>> com.google.gwt.dev.shell.BrowserChannelServer.reactToMessages(BrowserChanne lServer.java:308)
>> at
>> com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChan nelServer.java:547)
>> at
>> com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java :364)
>> at java.lang.Thread.run(Thread.java:662)
>> Caused by: java.io.EOFException: null
>> at java.io.DataInputStream.readByte(DataInputStream.java:250)
>> at
>> com.google.gwt.dev.shell.BrowserChannel$Message.readMessageType(BrowserChan nel.java:1100)
>> at
>> com.google.gwt.dev.shell.BrowserChannelServer.reactToMessages(BrowserChanne lServer.java:284)
>> at
>> com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChan nelServer.java:547)
>> at
>> com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java :364)
>> at java.lang.Thread.run(Thread.java:662)
>> On Tuesday, August 28, 2012 2:07:02 AM UTC+2, Brian Slesinsky wrote:
>>> That's an interesting report. We always want to garbage collect the
>>> ClassLoader when the session is over and if that doesn't happen, it's a bug.
>>> I don't know why Firefox would behave differently; the JVM side should work
>>> the same way for Firefox versus Chrome. The only thing I can think of is
>>> some difference in distributed garbage collection, but that shouldn't matter
>>> once the session ends.
>>> Alan's not on the team anymore. I'd like to fix this, but I'm busy with
>>> other things and I don't have a good idea where to begin. If someone's handy
>>> with a memory profiler, figuring out what's preventing the classloader from
>>> being gc-ed in this case would be very useful.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> To unsubscribe from this group, send email to
> google-web-toolkit+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-web-toolkit?hl=en.
On Tuesday, August 28, 2012 7:57:37 AM UTC-7, Brian Slesinsky wrote:
> Thanks, I think I can do something about this.
> On Tue, Aug 28, 2012 at 2:15 AM, Thomas Broyer wrote: > > In other words: it looks like the Firefox plugin doesn't send a > QuitMessage > > to the DevMode, and worse, is kept alive in the background!
> > On Tuesday, August 28, 2012 11:05:38 AM UTC+2, Chris Lercher wrote:
> >> I analyzed this a bit more (this time on Linux), and I noticed, that > the > >> number of Thread also grows: 1 thread per reload. Again, this happens > only > >> with Firefox, not with Chrome. So probably the ClassLoader references > will > >> be discarded only when the Thread terminates...
> >> One more thing that might be interesting: When closing the entire FF > >> instance (just closing the tab is not enough), then the threads are > >> discarded, and Heap/PermGen space can be garbage collected.
> >> By the way, closing the FF instance leads to the following Exception > >> printed by the DevMode server:
> >> 10:53:21.549 [ERROR] [mymodule] Remote connection lost
> >> com.google.gwt.dev.shell.BrowserChannel$RemoteDeathError: Remote > >> connection lost > >> at
> >> On Tuesday, August 28, 2012 2:07:02 AM UTC+2, Brian Slesinsky wrote:
> >>> That's an interesting report. We always want to garbage collect the > >>> ClassLoader when the session is over and if that doesn't happen, it's > a bug. > >>> I don't know why Firefox would behave differently; the JVM side should > work > >>> the same way for Firefox versus Chrome. The only thing I can think of > is > >>> some difference in distributed garbage collection, but that shouldn't > matter > >>> once the session ends.
> >>> Alan's not on the team anymore. I'd like to fix this, but I'm busy > with > >>> other things and I don't have a good idea where to begin. If someone's > handy > >>> with a memory profiler, figuring out what's preventing the classloader > from > >>> being gc-ed in this case would be very useful.
