|
|
|
|
Sponsored Link •
|
|
Advertisement
|
In many ways, the lifetime of a class in the Java virtual machine is similar to the lifetime of an object. The virtual machine creates and initializes objects, allows the program to use the objects, and optionally garbage collects the objects after they are no longer referenced by the program. Similarly, the virtual machine loads, links, and initializes classes, allows the program to use the classes, and optionally unloads the classes after they are no longer referenced by the program.
Garbage collection and unloading of classes is important in the Java virtual machine because Java programs can be dynamically extended at runtime by loading types through user-defined class loaders. All loaded types occupy memory space in the method area. If a Java application continuously loads types through user-defined class loaders, the memory footprint of the method area will continuously grow. If some of the dynamically loaded types are needed only temporarily, the memory space occupied by those types can be freed by unloading the types after they are no longer needed.
The way in which a Java virtual machine can tell whether a dynamically loaded type is still needed by the application is similar to the way it tells whether an object is still needed by the program. If the application has no references to the type, then the type can't affect the future course of computation. The type is unreachable and can be garbage collected.
Types loaded through the bootstrap class loader will always be reachable and never be unloaded. Only
types loaded through user-defined class loaders can become unreachable and be unloaded by the virtual
machine. A type is unreachable if its Class instance is found to be unreachable through
the normal process of garbage collecting the heap.
There are two ways a Class instance of a dynamically loaded type can be
reachable through the normal process of garbage collection. First and most obviously, a
Class instance will be reachable if the application holds an explicit reference to it.
Second, a Class instance will be reachable if there is a reachable object on the heap
whose type data in the method area refers to the Class instance. As mentioned in
Chapter 5, "The Java Virtual Machine," implementations must be able to locate the type data in the method
area for an object's class, given only a reference to the object. For this reason, the image of an object on the
heap likely includes some kind of pointer to its type data in the method area. From the type data, the virtual
machine must be able to locate the Class instances for the object's class, all its
superclasses, and all its superinterfaces. See Figure 7-2 for a graphical depiction of this way of "reaching"
Class instances.
Class instances through a reachable object.
Figure 7-2 shows the paths a garbage collector must traverse from a reachable object of class
MyThread through the type data in the method area to find reachable
Class instances. In this figure, objects on the heap are shown as clear circles; type data
in the method are is shown as gray rectangles. The MyThread class has the following
declaration:
// On CD-ROM in file classlife/ex8/MyThread.java
class MyThread extends Thread implements Cloneable {
}
From the reachable MyThread object (shown in the bottom right hand corner of the
figure), the garbage collector follows a pointer to MyThread's type data, where it
finds:
MyThread's Class instance on the
heap
MyThread's direct superinterface,
Cloneable
MyThread's direct superclass,
Thread
From the type data for Cloneable, the garbage collector finds:
Cloneable's Class instance on the
heap
From the type data for Thread, the garbage collector finds:
Thread's Class instance on the heap
Thread's direct superinterface,
Runnable
Thread's direct superclass,
Object
From the type data for Runnable, the garbage collector finds:
Runnable's Class instance on the
heap
From the type data for Object, the garbage collector finds:
Objects's Class instance on the heap
MyThread, the garbage
collector is able to "reach" the Class instances for MyThread
and all its supertypes: Cloneable, Thread,
Runnable, and Object.
An example of dynamically loaded classes becoming unreachable and available for unloading is given at the end of Chapter 8, "The Linking Model."
The CD-ROM contains the source code examples from this chapter in the
classlife directory.
For more information about the material presented in this chapter, visit the resources page:
http://www.artima.com/insidejvm/resources/
|
Sponsored Links
|