Elli I understand most of this. I do several things such as forcing a GC before doing the heap dump, from what you are say this may not be enough? Either way I'm not looking for an instance of the class to simply be there I'm looking at the GC Roots.
I also tried an additional step of after undeploying and finding I still had 2 GC roots I did a redeploy/undeploy. The results are: redeploy WebappClassLoader +1 (total 3) undeploy WebappClassLoader -1 (total 2) So generally the behaviour appears to be correct after the initial issue with the 1 class loader. It would also appear that at that point some form of GC has occured and cleaned up other instances. What I'm left with is that the rogue instance is is reachable and that it probably shouldn't be. As per the response to Mark and the JDK version it appears the gcroot is though sun.awt.AppContext Any thoughts? Additionally I'm going to try and find a slightly old version of java and check it's behaviour... Gerwood ________________________________________ From: Elli Albek [e...@sustainlane.com] Sent: Tuesday, 10 November 2009 9:52 AM To: Tomcat Users List Subject: Re: WebappClassLoader and undeploy Managing class loaders is done in the JVM. Tomcat cannot force the JVM to garbage collect class loaders, in the same way that it cannot force the JVM to garbage collect any object. If the class loader is unreachable, and all other objects that this class loader provided are also unreachable, then the JVM can garbage collect it like any other object. This garbage collection is heavier than simple object reference. I assume the JVM will do it only in major garbage collections and maybe even not in every major one. If your test app is not doing anything, there is no reason for the JVM to actually do something about it since memory is not consumed. If you try to force major garbage collections, eventually it should happen. If you run a load test, which will force tomcat to consume memory, then you will eventually get to a major garbage collection. This can take much longer than what you would think. If the code is simple (like JSP page and hello world type of servlet) it can be optimized by the JVM to consume memory on a local stack based heap (per thread), and not use the JVM main heaps. If you keep a reference to one object that was created from this class loader, then the Class object of this object is reachable, and the class loader is reachable via the Class. Since it is reachable, it cannot be garbage collected. WebappLoader is a class that has the code to manage a webapp lifecycle. It is not a class loader. The JVM to track references to it like any other simple object (String). In addition, it is an internal tomcat object, so it is a lot simpler to keep track of references to it in the tomcat code. It is not visible to the webapps or exposed to user code that can leak it. WebappClassLoader is the opposite: It is a real class loader. Garbage collecting it is not a simple matter. My guess is that: 1. If you constantly load the memory, then eventually it will be garbage collected. 2. If it is not garbage collected in that case, there is a reference leak, something is keeping a reference to either the class loader or to an object that was loaded by from it. Tomcat is releasing references to objects on its side, but the user code can do other things. If the web app contains one servlet and one JSP page, that should be easy to follow. Tomcat keeps references to those objects (both should be servlets), but also releases them when you redeploy. You can verify that the objects are gone. The actual instances should be gone very quickly since they are simple objects. JSP page is turned into a class, you should see it in the memory management tool. Notice that if the web app is reloaded, the new class loader will load the same classes again, so they will have the same class name, but they will have separate Class instances. You will have two objects that have the same class name, but are different class. Other possible reference leaks from the webapp to the outside: Threads that are left running JNDI Sessions Thread local Any library in a class loader above the webapp (in class loaders app, system, common and shared, possibly even in Catalina but less likely) Logging and reflection libraries always star as favorite leakers. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
