Thanks, I think I can do something about this. 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(BrowserChannelServer.java:308) >> at >> com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.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(BrowserChannel.java:1100) >> at >> com.google.gwt.dev.shell.BrowserChannelServer.reactToMessages(BrowserChannelServer.java:284) >> at >> com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.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. >>> >>> - Brian >>> > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/google-web-toolkit/-/5saLTgZ7UjEJ. > > To post to this group, send email to google-web-toolkit@googlegroups.com. > To unsubscribe from this group, send email to > google-web-toolkit+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en.
-- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
