Why >5000 GC root objects?
Hi,
using a JVMTI agent I found out that our application has more than 5000 root objects for GC. I would expect that there are some root objects for each thread used, but we only have ~20 Threads per process.
The list of roots shows lots of class objects (not all) and some other java.lang.* objects. But what I was wondering about is that several application specific objects are classified as roots too.
So, here are my questions:
1. In Java we have object trees. Does each tree has only one single root or several roots?
2. Do we even have several trees?
3. What is nessecary to classify an application object as root!
4. Why exist so many roots? Is it due to performance gain as shorter paths are necessary to identify an object as alive?
If you can tell me where I can find the answers (papers, books, ... ) it would be enough even though a direct answer is welcome too :-).
Thanks Robert
GC roots include:
1. Reference type locals of each frame of each thread
2.JNI global refs
3.JNI local refs of all "running" native methods. (i.e., any JNI native frame in some java thread)
-- the following could vary based on VM implementation
4.*internal* VM handles -- sort of like JNI handles but not exactly the same
5.*internal* static pointers in VM's C++ data structures
-- For example, often used/needed platform Java classes and objects
Although many tools report classes and/or static reference fields of classes as "roots" -- these are *not* roots. If a classloader is alive, then all the classes loaded by it are alive and therefore objects pointed from static (reference type) fields are alive as well. One exception: classes loaded by bootstrap loader are *never* unloaded (there is not even a classloader for these-- classloader is null). You can consider all the bootstrap classes as "roots".
> Although many tools report classes and/or static reference fields of classes as "roots" -- these are *not* roots. ...
As written the reporting tool is the JVMTI interface of an 1.5 JVM. reported as roots are the objects by the heap_root_callback from iterateOverReachableObjects(). I guess this reporting is correct, is it not?
Robert
Hi: The JVM TI spec. (near IterateOverReachableObjects) says:
The root objects comprise the set of system classes, JNI globals, references from thread stacks, and other objects used as roots for the purposes of garbage collection.
The above does not mention user's classes (i.e., anything not loaded by bootstrap loader). It is possible that there are many bootstrap classes are indeed loaded by the application (when JVM TI agent got the callback) -- given that there are many classes in rt.jar.
The last point I do not unterstand.
Indeed does all those >5000 roots (roots from application objects and other such as class objects) do NOT have a classloader (they do not have a reference of type 4 to a class loader). I checked this with a sample. If I understand you right: this means the are loaded by the bootstrap loader.
But those objects do not reside in rt.jar in the Java Runtime Env. directoy. How could this be?
Is the bootstrap loader responsible for that (all) its loaded classes become roots?
Robert
You said
> But those objects do not reside in rt.jar in the Java Runtime Env. directoy. How could this be?
I guess you meant those classes (and not objects) are not in rt.jar? Or yoou meant Class objects? In any case, please note that any class loaded by boot loader are always alive. The bootstrap classes could be loaded from other jar files as well - - not necessarily the ones loaded from rt.jar. Bootstrap classpath from a JDK 6 installation (on my machine) is as follows:
d:\jdk1.6.0\jre\lib\resources.jar;d:\jdk1.6.0\jre\lib\rt.jar;d:\jdk1.6.0\jre\lib
\sunrsasign.jar;d:\jdk1.6.0\jre\lib\jsse.jar;d:\jdk1.6.0\jre\lib\jce.jar;d:\jdk1
.6.0\jre\lib\charsets.jar;d:\jdk1.6.0\jre\classes
Also, if you change boot classpath using -Xbootclasspath option, then bootstrap classes could come from your (confiured) path as well.
And yes, all bootstrap classes are always alive -- never unloaded.
At first: what I call roots in the sense of JVMTI are those "always alive bootstrap loaded classes" ?
Then with that my problem is that I do not only have class objects as roots. There are several thread objects, error and exception objects and even byte/short/integer array elements which are classified as roots. Additional there are those application OBJECTS which are classified as roots.
Its seems to me that you always speak about class objects as roots, but I have about 60% out of those 5000 roots as normal objects.
[Bootstrap classpath]
All classes from this class path become roots as they are loaded by the bootstrap loader?
--Robert
>There are several thread objects, error and exception objects and even >byte/short/integer array elements which are classified as roots. Additional >there are those application OBJECTS which are classified as roots.
Because these are references to these objects
a) in some frame of some java threads or
b) referenced by some JNI global ref
c) referenced by some JNI local frame (from JNI native frame of some thread stack)
You may want classify the roots by root kind (one of the JVM TI defined constants JVMTI_HEAP_ROOT_JNI_GLOBAL, JVMTI_HEAP_ROOT_SYSTEM_CLASS, JVMTI_HEAP_ROOT_MONITOR, JVMTI_HEAP_ROOT_THREAD, or JVMTI_HEAP_ROOT_OTHER) and check out.
> [Bootstrap classpath]
>All classes from this class path become roots as they are loaded by the >bootstrap loader?
Yes, all bootstrap classes are roots with the root kind of JVMTI_HEAP_ROOT_SYSTEM_CLASS
Ok, all those application classes are of type 1 (JVMTI_HEAP_ROOT_JNI_GLOBAL). As I never came in touch with such heap internals could you explain what this means (beeing type 1) and what it is about with such JNI global reference?Thanks Robert
This section of the JNI spec provides a description of JNI global references: http://java.sun.com/j2se/1.5.0/docs/guide/jni/spec/design.html#wp1242
