Thanks so much for digging into this, Stephen. @John, Bob, Ray: can you guys take a look at this and maybe create yourselves issues? It seems like this is a real performance issue, with the user ending up in sluggish performance or else having to restart DevMode, which is certainly slower than refresh.
On Tue, Aug 10, 2010 at 1:32 AM, Stephen Haberman <[email protected]>wrote: > > > Is the number of JRealClassType instances just going up and up each > refresh? > > Yep. I didn't explicitly check until you asked, but comparing heap diffs > before/after multiple refreshes, each refresh was adding ~1800 new > JRealClassTypes that never went away. > > > Can you figure out who is holding references to them (referrants)? > > Turns out I can. Thank you for the rather logical suggestion--I had > looked at the GC root paths and, once I saw AppClassLoader, had given up > thinking it was going to be an PITA classloader issue. > > But, no, its just some static caches. It took a few tries, but the > attached patch "fixes" the leaks and I can now run my whole test suite > and DevMode stays snappy. > > Note that I use the term "fixes" very loosely as: > > * ResourceFactory.cache just needs a WeakHashMap, pretty easy > > * OwnerFieldClass.FIELD_CLASSES needs a hash map that is weak on both > keys and values. Or some way to explicitly clear the values when > the TypeOracle is done with. > > I tried a WeakHashMap and it was not enough as the OwnerFieldClass > value is what holds the JRealClassType reference. What did work, was a > stupid, ugly hack of clearing the cache on each new oracle seen (which > is a bad idea, it would break multiple clients use DevMode > concurrently, but it proved the point). > > * AbstractResourceContext.CACHES is already a WeakHashMap, however, the > values end up being IdentityHashMaps with JRealClassTypes keys, which > reference the oracle, so, contrary to the javadoc, it does actually > keep TypeOracles from being GC'd. > > The same ugly hack from issue 2 also solved this final one. > > As my hacks obviously show, I don't know of a good way to deal with the > 2nd or 3rd issues. If you have a suggestion, I can try and run with it, > but I'd also be just fine with someone more knowledgeable about the > codebase finding an elegant solution. :-) > > Thanks! > > - Stephen > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
