📄 constantpool.doc.html
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>VM Spec Constant Pool Resolution</title>
</head>
<body BGCOLOR=#eeeeff text=#000000 LINK=#0000ff VLINK=#000077 ALINK=#ff0000>
<table width=100%><tr>
<td><a href="VMSpecTOC.doc.html">Contents</a> | <a href="ClassFile.doc.html">Prev</a> | <a href="Instructions.doc.html">Next</a> | <a href="Lindholm.INDEX.html">Index</a></td><td align=right><i><i>The Java<sup><font size=-2>TM</font></sup> Virtual Machine Specification</i></i></td>
</tr></table>
<hr><br>
<a name="67469"></a>
<p><strong>CHAPTER 5 </strong></p>
<a name="67499"></a>
<h1>Constant Pool Resolution</h1>
<hr><p>
<a name="67509"></a>
Java classes and interfaces are dynamically loaded <a href="Concepts.doc.html#19175">(§2.16.2)</a>, linked <a href="Concepts.doc.html#22574">(§2.16.3)</a>, and
initialized <a href="Concepts.doc.html#19075">(§2.16.4)</a>. Loading is the process of finding the binary form of a class or
interface type with a particular name and constructing, from that binary form, a <code>Class</code>
object to represent the class or interface. Linking is the process of taking a binary
form of a class or interface type and combining it into the runtime state of the Java
Virtual Machine so that it can be executed. Initialization of a class consists of executing its static initializers and the initializers for static fields declared in the class.
<p><a name="65509"></a>
The Java Virtual Machine performs most aspects of these procedures through operations on a constant pool <a href="ClassFile.doc.html#20080">(§4.4)</a>, a per-type runtime data structure that serves many of the purposes of the symbol table of a conventional language. For example, Java Virtual Machine instructions that might otherwise have been designed to take immediate numeric or string operands instead fetch their operands from the constant pool. Classes, methods, and fields, whether referenced from Java Virtual Machine instructions or from other constant pool entries, are named using the constant pool.<p>
<a name="65422"></a>
A Java compiler does not presume to know the way in which a Java Virtual Machine lays out classes, interfaces, class instances, or arrays. References in the constant pool are always initially symbolic. At run time, the symbolic representation of the reference in the constant pool is used to work out the actual location of the referenced entity. The process of dynamically determining concrete values from symbolic references in the constant pool is known as <i>constant pool resolution</i>. Constant pool resolution may involve loading one or more classes or interfaces, linking several types, and initializing types. There are several kinds of constant pool entries, and the details of resolution differ with the kind of entry to be resolved.<p>
<a name="65405"></a>
Individual Java Virtual Machine instructions that reference entities in the constant pool are responsible for resolving the entities they reference. Constant pool entries that are referenced from other constant pool entries are resolved when the referring entry is resolved. <p>
<a name="67067"></a>
A given constant pool entry may be referred to from any number of Java Virtual Machine instructions or other constant pool entries; thus, constant pool resolution can be attempted on a constant pool entry that is already resolved. An attempt to resolve a constant pool entry that has already been successfully resolved always succeeds trivially, and always results in the same entity produced by the initial resolution of that entry.<p>
<a name="66684"></a>
Constant pool resolution is normally initiated by the execution of a Java Virtual Machine instruction that references the constant pool. Rather than give the full description of the resolution process performed by Java Virtual Machine instructions in their individual descriptions, we will use this chapter to summarize the constant pool resolution process. We will specify the errors that must be detected when resolving each kind of constant pool entry, the order in which those errors must be responded to, and the errors thrown in response.<p>
<a name="50875"></a>
When referenced from the context of certain Java Virtual Machine instructions, additional constraints are put on linking operations. For instance, the <i>getfield</i> instruction requires not only that the constant pool entry for the field it references can be successfully resolved, but also that the resolved field is not a class (<code>static</code>) field. If it is a class field, an exception must be thrown. Linking exceptions that are specific to the execution of a particular Java Virtual Machine instruction are given in the description of that instruction and are not covered in this general discussion of constant pool resolution. Note that such exceptions, although described as part of the execution of Java Virtual Machine instructions rather than constant pool resolution, are still properly considered failure of the linking phase of Java Virtual Machine execution.<p>
<a name="61405"></a>
The Java Virtual Machine specification documents and orders all exceptions that can arise as a result of constant pool resolution. It does not mandate how they should be detected, only that they must be. In addition, as mentioned in <a href="Instructions.doc.html#66654">§6.3</a>, any of the virtual machine errors listed as subclasses of <code>VirtualMachineError</code> may be thrown at any time during constant pool resolution.<p>
<a name="51579"></a>
<hr><h2>5.1 Class and Interface Resolution</h2>
<a name="49434"></a>
A constant pool entry tagged as <code>CONSTANT_Class</code> <a href="ClassFile.doc.html#1221">(§4.4.1)</a> represents a class or
interface. Various Java Virtual Machine instructions reference <code>CONSTANT_Class</code>
entries in the constant pool of the class that is current upon their execution
<a href="Overview.doc.html#17257">(§3.6)</a>. Several other kinds of constant pool entries <a href="ClassFile.doc.html#4723">(§4.4.2)</a> reference
<code>CONSTANT_Class</code> entries and cause those class or interface references to be
resolved when the referencing entries are resolved. For instance, before a
method reference (a <code>CONSTANT_Methodref</code> constant pool entry) can be resolved,
the reference it makes to the class of the method (via the <code>class_index</code> item of the
constant pool entry) must first be resolved.
<p><a name="66210"></a>
If a class or interface has not been resolved already, the details of the resolution process depend on what kind of entity is represented by the <code>CONSTANT_Class</code> entry being resolved. Array classes are handled differently from non-array classes and from interfaces. Details of the resolution process also depend on whether the reference prompting the resolution of this class or interface is from a class or interface that was loaded using a class loader <a href="Concepts.doc.html#19175">(§2.16.2)</a>.<p>
<a name="66845"></a>
The <code>name_index</code> item of a <code>CONSTANT_Class</code> constant pool entry is a reference to a <code>CONSTANT_Utf8</code> constant pool entry <a href="ClassFile.doc.html#7963">(§4.4.7)</a> for a UTF-8 string that represents the fully qualified name <a href="Concepts.doc.html#20207">(§2.7.9)</a> of the class or interface to be resolved. What kind of entity is represented by a <code>CONSTANT_Class</code> constant pool entry, and how to resolve that entry, is determined as follows:<p>
<ul><a name="66184"></a>
<li>If the first character of the fully qualified name of the constant pool entry to be resolved is not a left bracket ("<code>[</code>"), then the entry is a reference to a non-array class or to an interface.
<a name="66858"></a>
<li>If the current class <a href="Overview.doc.html#17257">(§3.6)</a> has not been loaded by a class loader, then "normal" class resolution is used <a href="ConstantPool.doc.html#65190">(§5.1.1)</a>.
<a name="66773"></a>
<li>If the current class has been loaded by a class loader, then application-defined code is used <a href="ConstantPool.doc.html#67374">(§5.1.2)</a> to resolve the class.
<a name="66780"></a>
<li>If the first character of the fully qualified name of the constant pool entry to be resolved is a left bracket ("<code>[</code>"), then the entry is a reference to an array class. Array classes are resolved specially <a href="ConstantPool.doc.html#65204">(§5.1.3)</a>.
</ul><a name="65190"></a>
<h3>5.1.1 Current Class or Interface Not Loaded by a Class Loader</h3>
<a name="67598"></a>
If a class or interface that has been loaded, and that was not loaded using a class
loader, references a non-array class or interface C, then the following steps are performed to resolve the reference to C:
<p><ol>
<a name="67945"></a>
<li>The class or interface C and its superclasses are first loaded <a href="Concepts.doc.html#19175">(§2.16.2)</a>.
<a name="67947"></a>
<li>If class or interface C<code> </code>has not been loaded yet, the Java Virtual Machine will search for a file C<code>.class</code> and attempt to load class or interface C from that file. Note that there is no guarantee that the file C<code>.class</code> will actually contain the class or interface C, or that the file C<code>.class</code> is even a valid <code>class</code> file. It is also possible that class or interface C might have already been loaded, but not yet initialized. This phase of loading must detect the following errors:
<ul>
<a name="51442"></a>
<li>If no file with the appropriate name can be found and read, class or interface resolution throws a <code>NoClassDefFoundError</code>.
<a name="51449"></a>
<li>Otherwise, if it is determined that the selected file is not a well-formed <code>class</code> file (pass 1 of <a href="ClassFile.doc.html#9766">§4.9.1</a>), or is not a <code>class</code> file of a supported major or minor version (<a href="ClassFile.doc.html#21045">§4.1)</a>, class or interface resolution throws a <code>NoClassDefFoundError</code>.
<a name="51459"></a>
<li>Otherwise, if the selected <code>class</code> file did not actually contain the desired class or interface, class or interface resolution throws a <code>NoClassDefFoundError</code>.
<a name="51469"></a>
<li>Otherwise, if the selected <code>class</code> file does not specify a superclass and is not the <code>class</code> file for class <code>Object</code>, class or interface resolution throws a <code>ClassFormat-Error</code>.
</ul>
<a name="38907"></a>
<li>If the superclass of the class being loaded has not yet been loaded, it is loaded using this step 1 recursively. Loading a superclass must detect any of the errors in step 1a, where this superclass is considered to be the class being loaded. Note that all interfaces must have <code>java.lang.Object</code> as their superclass, which must already have been loaded.
<a name="66889"></a>
<li>If loading class C and its superclasses was successful, the superclass (and thus its superclasses, if any) of class C is linked and initialized by applying steps -2-4 recursively.
<a name="65953"></a>
<li>The class C is linked <a href="Concepts.doc.html#22574">(§2.16.3)</a>, that is, it is verified <a href="ClassFile.doc.html#8051">(§4.9)</a> and prepared.
<a name="65959"></a>
<li>First, the class or interface C is verified to ensure that its binary representation is structurally valid (passes 2 and 3 of <a href="ClassFile.doc.html#9766">§4.9.1</a>).<a href="#67167"><sup>1</sup></a> Verification may itself cause classes and interfaces to be loaded, but not initialized (to avoid circularity), using the procedure in step 1.
<ul>
<a name="65571"></a>
<li>If the class or interface C contained in <code>class</code> file C<code>.class</code> does not satisfy the static or structural constraints on valid <code>class</code> files listed in <a href="ClassFile.doc.html#8771">Section 4.8, "Constraints on Java Virtual Machine Code,"</a> class or interface resolution throws a <code>VerifyError</code>.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -