On 17/02/2016 11:11, Mark Thomas wrote: > On 16/02/2016 22:07, Ty wrote: >>> Exactly which versions were you using when you ran your tests? >> >> According to my notes: 7.0.59, which should've been the most recent >> version available at the time (about this time last year). >> >> To clarify: that was the version we did a heap dump analysis of, and noted >> the memory increase related to Manifest objects. The version used for the >> test procedure in this thread's original message -- last performed last >> week -- was 7.0.67 and we did not do a heap analysis of it (only noting >> that at a glance it resulted in approximately the same amount of heap >> increase correlating with JAR scanning as we saw with last year's version). > > Thanks for the version info. > > I've started looking at this. The bulk of the memory is used by > JarResourceSet. It is caching a JarFileEntry object for each class in > the JAR. > > I wrote this code but I don't recall why those entries were retained. I > need to look back through svn to figure out what problem it was solving > and then see if I can find a better solution.
Quick update. There are two separate issues, both triggered by JAR scanning. The JarResourceSet issue above accounts for ~50% of a 1GB heap. There is also a WebappClassLoader issue that accounts for ~30% of the same heap. The WebappClassLoader issue is the easier to fix. I have fixed this in trunk and am just waiting for the tests to confirm all is well. I plan to back-port this to 8.0.x for the next release. The JarResourceSet is going to be trickier. The code is the way it is partly for performance, partly to avoid file locking on Windows. It is going to take a little longer to put together a fix for this one. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
