https://issues.apache.org/bugzilla/show_bug.cgi?id=51195
--- Comment #7 from Christopher Schultz <ch...@christopherschultz.net> 2011-05-24 13:59:07 UTC --- Joern, (In reply to comment #6) > The cleanup performed in the code is merely to prevent a *false* memory leak > warning. A real leak does, in fact, not exist. This is the reason why I put it > directly before the execution of System.gc() in the "Find Leaks" function. One could argue that a memory leak does, in fact, exist: just because the references will be /eventually/ collected doesn't mean that they won't loiter for quite a long time... unless the GC is getting seriously low on memory, those objects will stick in memory, and so, likely, will the WebappClassLoader, and all of the java.lang.Class objects it manages. I agree with Mark that this feature is best placed into WebappClassLoader and run during it's disposal sequence. > Since "Find Leaks" isn't supposed to be executed in a production environment, > I > don't think that any further optimization (suggestion in 2.) makes sense. If this will be used in WebappClassLoader, such optimizations should obviously be made. > It > would probably make sense if this code would indeed be added to the normal > undeploy procedure but I really don't think that this is necessary or > advisable. This could be implemented as a utility method accessible to both pieces of code, and called directly during a "find leaks" operation... I would have to look at the "find leaks" feature to see if that would even be necessary... my sense is that the WCL is disposed before the leaks are detected, so I don't think any changes to the manager app would need to be made. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
