My apologies if this is a beginner question, and not related to the EAP. (Perhaps a 'general' or 'users' forum would be a nice addition?)
I'm using the following configuration:
-YourKit 4.5 EAP build 610
-Sun JDK 1.5.0_03 on Win 2000
-Tomcat 5.5.9
I'm trying to debug webapp classloader leaks that we're seeing on redeployment.
All the leaked classloaders (org.apache.catalina.loader.WebappClassloader) are marked as "Unknown" GC roots).
Is there any way get more information who's referencing there classes?
Unknown GC roots, any hints?
-
- Posts: 6172
- Joined: Wed Aug 11, 2004 8:37 am
-
- Posts: 314
- Joined: Thu Jun 02, 2005 8:36 pm
Hello Anton,
I don't have a reproducible testcase using the Tomcat sample applications.
However, I have something that is (I hope) almost as good:
A sample WAR file containing:
-spring.jar
-commons-logging.jar
-log4j.jar
-minimal web.xml
-minimal log4j.properties
-minimal leak-servlet.xml (Spring framework servlet context configuration)
Please note that this WAR file contains no custom classes at all (just the libraries mentioned above).
In essence, the WAR file contains a very basic Spring framework configuration, some logging, and nothing more.
I have been doing deployment tests with this WAR on a 'out of the box' Tomcat 5.5.9 (last stable version) on both JDK 1.5.0_04 and Mustang b42, capturing memory snapshots using EAP release 618.
Please let me know how I can provide the sample WAR and/or snapshots to you, if you are interested.
The behaviour that I see it that the (Tomcat/Catalina) WebappClassloader that loads my webapplication is marked as an "Unknown" GC root. This manifests itself when I undeploy the application using the Tomcat HTML manager app: while the application is removed from the list, a lot of data is kept referenced in memory, showing the particular WebappClassloader as a GC root.
I don't understand the "what" and "why" of JVMTI 'Unknown' roots. Do these indicate a JVM bug or am I just reading the results without the right knowledge and experience? Isn't the whole point of modern virtualized execution environments like the JVM to get rid of the 'unknown' in memory management?
I don't have a reproducible testcase using the Tomcat sample applications.
However, I have something that is (I hope) almost as good:
A sample WAR file containing:
-spring.jar
-commons-logging.jar
-log4j.jar
-minimal web.xml
-minimal log4j.properties
-minimal leak-servlet.xml (Spring framework servlet context configuration)
Please note that this WAR file contains no custom classes at all (just the libraries mentioned above).
In essence, the WAR file contains a very basic Spring framework configuration, some logging, and nothing more.
I have been doing deployment tests with this WAR on a 'out of the box' Tomcat 5.5.9 (last stable version) on both JDK 1.5.0_04 and Mustang b42, capturing memory snapshots using EAP release 618.
Please let me know how I can provide the sample WAR and/or snapshots to you, if you are interested.
The behaviour that I see it that the (Tomcat/Catalina) WebappClassloader that loads my webapplication is marked as an "Unknown" GC root. This manifests itself when I undeploy the application using the Tomcat HTML manager app: while the application is removed from the list, a lot of data is kept referenced in memory, showing the particular WebappClassloader as a GC root.
I don't understand the "what" and "why" of JVMTI 'Unknown' roots. Do these indicate a JVM bug or am I just reading the results without the right knowledge and experience? Isn't the whole point of modern virtualized execution environments like the JVM to get rid of the 'unknown' in memory management?