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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
