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 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 > > after restarting DevMode (see e.g. > https://groups.google.com/d/topic/google-web-toolkit/btPIOoriq_o/discussion > , http://code.google.com/p/google-web-toolkit/issues/detail?id=4312 , > http://code.google.com/p/google-web-toolkit/issues/detail?id=4514 , ...). > It would also explain, why it's often dismissed as "cannot reproduce" > (because it cannot be reproduced with Chrome). But when stopping a DevMode > server that is (nearly) out of memory, it may hang. And you usually won't > see an error message (the reason why I finally found this issue, is that I > did get it a few times now). Plus, in Eclipse it looks as if DevMode had > already terminated (the red stop button turns gray). > > *Question:* > > Is it a good idea to create another new issue for this? I'd like to ask > here first, if anybody knows what the Status is? @AlanLeung? > -- 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/-/I3cf0A4RHKUJ. 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.
