JVM学习笔记-动态连接和解析（Dynamic Linking and Resolution)

 

When you compile a Java program, you get a separate class file for each class or interface in your program. Although the individual class files may appear to be independent, they actually harbor symbolic connections to one another and to the class files of the Java API. When you run your program, the Java Virtual Machine loads your programís classes and interfaces and hooks them together in a process of dynamic linking. As your program runs, the Java Virtual Machine builds an internal web of interconnected classes and interfaces.

当编译Java程序的时候，会得到程序中每一个类或者接口的独立的class文件。虽然独立看上去毫无关联，但是他们之间通过接口(harbor)符号互相联系，或者与Java API的class文件相联系。当运行程序的时候，Java虚拟机装载程序的类和接口，并且在动态连接的过程中把它们互相勾连起来。在程序运行中，Java虚拟机内部组织了一张互相连接的类和接口的网。

 

A class file keeps all its symbolic references in one place, the constant pool. Each class file has a constant pool, and each class or interface loaded by the Java Virtual Machine has an internal version of its constant pool. The internal constant pool is an implementation-specific data structure that maps to the constant pool in the class file. Thus, after a type is initially loaded, all the symbolic references from the type reside in the typeís internal constant pool.

class把他们所有的引用符号放在一个地方——常量池。每一个class文件有一个常量池，每一个被Java虚拟机装载的类或者接口都有一份内部版本常量池，被称作运行时常量池。运行时常量池是特定与实现的数据结构，数据结构映射到class文件中的常量池。因此，当一个类型被首次装载的时候，所有来自于类型的符号引用都装载到了类型的运行时常量池。 

 

At some point during the running of a program, if a particular symbolic reference is to be used, it must be resolved. Resolution is the process of finding the entity identified by the symbolic reference and replacing the symbolic reference with a direct reference. Because all symbolic references reside in the constant pool, this process is often called constant pool resolution.

在程序运行的过程中，如果某个特定的符号引用将要被使用，它首先要被解析。解析过程就是首先根据符号引用查找到实体，再把符号引用替换成直接引用的过程。因为所有的符号引用都是保存在常量池中，所以这种解析叫做常量池解析。

 

As described in Chapter 6, "The Java Class File," the constant pool is organized as a sequence of items. Each item has a unique index, much like an array element. A symbolic reference is one kind of item that may appear in the constant pool. Java Virtual Machine instructions that use a symbolic reference specify the index in the constant pool where the symbolic reference resides. For example, the getstatic opcode, which pushes the value of a static field onto the stack, is followed in the bytecode stream by an index into the constant pool. The constant pool entry at the specified index, a CONSTANT_Fieldref_info entry, reveals the fully qualified name of the class in which the field resides, and the name and type of the field.

 

在第6章中描述过,常量池按照一系列项组织。每一项拥有一个唯一的索引，很像数组元素。符号引用是可以出现在常量池的一种项目。使用符号引用的Java虚拟机指令指定位于常量池中的符号引用的索引。比如，getstatic操作码(它把一个静态字段的值压入栈中）在字节码流中会跟有一个常量池索引。常量池中指定索引指向的入口，是一个Constant_Fieldref_info入口，它显示出这个字段所在类的全限定名以及字段的名字和类型。

 

 

Keep in mind that the Java Virtual Machine contains a separate internal constant pool for each class and interface it loads. When an instruction refers to the fifth item in the constant pool, it is referring to the fifth item in the constant pool for the current class, the class that defined the method the Java Virtual Machine is currently executing.

 

记住,java虚拟机为每一个装载的类和接口保存一份独立的常量池。当一条指令引用常量池的第5个元素的时候，它指向的是当前类的常量池中的第5个元素，即定义Java虚拟机当前正执行的方法的类。

 

Several instructions, from the same or different methods, may refer to the same constant pool entry, but each constant pool entry is resolved only once. After a symbolic reference has been resolved for one instruction, subsequent attempts to resolve it by other instructions take advantage of the hard work already done, and use the same direct reference resulting from the original resolution.

Linking involves not only the replacement of symbolic references with direct ones, it also involves checking for correctness and permission. As mentioned in Chapter 7, "The Lifetime of a Class," the checking of symbolic references for existence and access permission (one aspect of the full verification phase) is likely performed during resolution. For example, when a Java Virtual Machine resolves a getstatic instruction to a field of another class, the Java Virtual Machine checks to make sure that:

• The other class exists.
• This class has permission to access the other class.
• The named field exists in the other class.
• The field has the expected type (symbolic references to fields include the field type).
• This class has permission to access the field.
• That the field is really static--a class variable and not an instance variable.

If any of these checks fail, an error is thrown and resolution fails. Otherwise, the symbolic reference is replaced by the direct reference and resolution succeeds.

 

As described in Chapter 7, "The Lifetime of a Class," different implementations of the Java Virtual Machine are permitted to perform resolution at different times during the execution of a program. An implementation may choose to link everything up front by following all symbolic references from the initial class, then all symbolic references from subsequent classes, until every symbolic reference has been resolved. In this case, the application would be completely linked before its main() method was ever invoked. This approach is called early resolution. Alternatively, an implementation may choose to wait until the very last minute to resolve each symbolic reference. In this case, the Java Virtual Machine would resolve a symbolic reference only when it is first used by the running program. This approach is called late resolution. Other implementations could choose a resolution strategy in-between these two extremes.

 

Although a Java Virtual Machine implementation has some freedom in choosing when to resolve symbolic references, every Java Virtual Machine must give the outward impression that it uses late resolution. No matter when a particular Java Virtual Machine performs its linking, it will always throw any error that results from attempting to resolve a symbolic reference at the point in the execution of the program where the symbolic reference was actually used for the first time. In this way, it will always appear to the user as if the linking were late. If a Java Virtual Machine does early linking, and during early linking discovers that a class file is missing, it wonít report the class file missing by throwing the appropriate error until later in the program when something in that class file is actually used. If the class is never used by the program, the error will never be thrown.