[Switch] Analysis of JVM loader System and hot update (2)

Similarly, a class object must know its own superclasses and superinterfaces. Therefore, the Class Object references the class object of its own superclass and superinterfaces. This type of reference must be instance reference. (In fact, superclasses and superinterfaces are also stored in the constant pool. However, to differentiate references of dependent classes, we will express them in a special way .)

So now I have two conclusions.

Conclusion 1: If you hold a reference to a class object, it is impossible to detach any class that the class object directly or indirectly depends on (if it is loaded. Similarly, as long as a class directly or indirectly depends on a class, the class cannot be detached.

Conclusion 2: When a class object is referenced, all superclasses and superinterfaces of the class cannot be detached. Similarly, if any class (or interface) has a subclass (or implementation class or sub-interface) that has not been uninstalled, the class (Interface) cannot be uninstalled.

It can be seen that for a software, all its class files can be viewed as a set of Accessible Nodes from the root node containing the main method, and all reachable nodes can be searched in a dependency graph. The vast majority of classes in this set are either stored in the memory or all are detached.

For a module, if the classes of the module depend on each other, the module must be uninstalled. Therefore, if an application wants to use one module to detach another module. The necessary condition is that the module that executes the uninstallation operation must be independent of the unmounted module.

Zero dependency means that the dependent modules are completely transparent and invisible.

According to the above conclusion, the uninstallation must be in the unit of modules. Therefore, it is impossible to uninstall a strongly coupled class. Therefore, I can say "Uninstall class" instead of "Uninstall module ".

So what are the conditions for uninstalling a module?

Return to the reference relationship diagram above. Let's take a look at the other elements that may reference the class object.

For any Java object, it must be an instance of a class. Therefore, it can directly or indirectly reference the class object of this class. There are three reasons for this inference: first, JVM must know the object type when performing a downward transformation and instanceof determination. If the object cannot be referenced to the Class Object of the class, how can this process be implemented? Second, the subclass can override the parent class method. The running polymorphism allows the virtual machine to call the object method correctly (to prevent the subclass from calling the method overwritten by the parent class). If you do not know the object type, why? Third, the object class has a native method getclass () to directly obtain the Class Object of the object.

After a class is loaded by the class loader, when the class name of the class is accepted for the second time, the loader will directly return the class object instead of loading the class repeatedly. The virtual machine never allows a class in the same namespace to be loaded twice. Therefore, the Class Loader must cache all class objects loaded by the class for returning.

In addition, classloader or class object can be referenced by variables. If some reachable variables (local variables, member variables, static variables) reference them, it will naturally make the entire module reachable and unmount.

In addition, some special class loaders are always accessible, including Bootstrap, extendsion, and system. Therefore, I can draw a conclusion.

Conclusion 3: Once the java standard class library is loaded, it cannot be uninstalled.

Conclusion 4: Classes in class_path (Classes loaded by the system loader) cannot be detached Once loaded.

Therefore, all classes in a module must be loaded using the same classloader instance. The classloader instance cannot be extendsion or system. The control of this classloader instance must be in the unmounted module. Release the instance reference at any time to make classloader inaccessible.

In addition, instances of any class of this module must be inaccessible. The module cannot be released if any class of this module is accessible.

So far, I have obtained the sufficient condition for uninstalling the module: all classes of the module are loaded by a controllable classloader, And the definition class loader of the module is released for reference; release instance references of all classes of this module; release Class Object references of this module.

Also, the module defines the class loaders, class instances, and class objects. As long as they are not referenced in other modules, they are not in the stack memory, you can uninstall the module. In particular, the module itself references these things, especially the static variables of the module reference these things, which completely does not affect the uninstallation.

One idea is that the root node determined by garbage collection includes static variables of all classes, which is wrong. In fact, if a module becomes inaccessible, the static variables of all its classes will become inaccessible and will be recycled and released.

 

Transferred from:

Http://taozeyu.com/software/2014/03/15/jvm-class-loader-2.html

[Switch] Analysis of JVM loader System and hot update (2)