5.1运行时常量池

The Java Virtual Machine maintains a run-time constant pool for each class and interface (§2.5.5). This data structure serves many of the purposes of the symbol table of a conventional programming language implementation. The constant_pool table in the binary representation of a class or interface (§4.4) is used to construct the run-time constant pool upon class or interface creation (§5.3). There are two kinds of entry in the run-time constant pool: symbolic references, which may later be resolved (§5.4.3), and static constants, which require no further processing. The symbolic references in the run-time constant pool are derived from entries in the constant_pool table in accordance with the structure of each entry:

  • A symbolic reference to a class or interface is derived from a CONSTANT_Class_info structure (§4.4.1). Such a reference gives the name of the class or interface in the following form:

    • For a nonarray class or an interface, the name is the binary name (§4.2.1) of the class or interface.

    • For an array class of n dimensions, the name begins with n occurrences of the ASCII [ character followed by a representation of the element type:

      • If the element type is a primitive type, it is represented by the corresponding field descriptor (§4.3.2).

      • Otherwise, if the element type is a reference type, it is represented by the ASCII L character followed by the binary name of the element type followed by the ASCII ; character.

        Whenever this chapter refers to the name of a class or interface, the name should be understood to be in the form above. (This is also the form returned by the Class.getName method.)

  • A symbolic reference to a field of a class or an interface is derived from a CONSTANT_Fieldref_info structure (§4.4.2). Such a reference gives the name and descriptor of the field, as well as a symbolic reference to the class or interface in which the field is to be found.

  • A symbolic reference to a method of a class is derived from a CONSTANT_Methodref_info structure (§4.4.2). Such a reference gives the name and descriptor of the method, as well as a symbolic reference to the class in which the method is to be found.

  • A symbolic reference to a method of an interface is derived from a CONSTANT_InterfaceMethodref_info structure (§4.4.2). Such a reference gives the name and descriptor of the interface method, as well as a symbolic reference to the interface in which the method is to be found.

  • A symbolic reference to a method handle is derived from a CONSTANT_MethodHandle_info structure (§4.4.8). Such a reference gives a symbolic reference to a field of a class or interface, or a method of a class, or a method of an interface, depending on the kind of the method handle.

  • A symbolic reference to a method type is derived from a CONSTANT_MethodType_info structure (§4.4.9). Such a reference gives a method descriptor (§4.3.3).

  • A symbolic reference to a dynamically-computed constant is derived from a CONSTANT_Dynamic_info structure (§4.4.10). Such a reference gives:

    • a symbolic reference to a method handle, which will be invoked to compute the constant’s value;

    • a sequence of symbolic references and static constants, which will serve as static arguments when the method handle is invoked;

    • an unqualified name and a field descriptor.

  • A symbolic reference to a dynamically-computed call site is derived from a CONSTANT_InvokeDynamic_info structure (§4.4.10). Such a reference gives:

    • a symbolic reference to a method handle, which will be invoked in the course of an invokedynamic instruction (§invokedynamic) to compute an instance of java.lang.invoke.CallSite;

    • a sequence of symbolic references and static constants, which will serve as static arguments when the method handle is invoked;

    • an unqualified name and a method descriptor. The static constants in the run-time constant pool are also derived from entries in the constant_pool table in accordance with the structure of each entry:

  • A string constant is a reference to an instance of class String, and is derived from a CONSTANT_String_info structure (§4.4.3). To derive a string constant, the Java Virtual Machine examines the sequence of code points given by the CONSTANT_String_info structure:

    • If the method String.intern has previously been invoked on an instance of class String containing a sequence of Unicode code points identical to that given by the CONSTANT_String_info structure, then the string constant is a reference to that same instance of class String.

    • Otherwise, a new instance of class String is created containing the sequence of Unicode code points given by the CONSTANT_String_info structure. The string constant is a reference to the new instance. Finally, the method String.intern is invoked on the new instance.

  • Numeric constants are derived from CONSTANT_Integer_info, CONSTANT_Float_info, CONSTANT_Long_info, and CONSTANT_Double_info structures (§4.4.4, §4.4.5).

    Note that CONSTANT_Float_info structures represent values in IEEE 754 single format and CONSTANT_Double_info structures represent values in IEEE 754 double format. The numeric constants derived from these structures must thus be values that can be represented using IEEE 754 single and double formats, respectively. The remaining structures in the constant_pool table - the descriptive structures CONSTANT_NameAndType_info, CONSTANT_Module_info, and CONSTANT_Package_info, and the foundational structure CONSTANT_Utf8_info - are only used indirectly when constructing the run-time constant pool. No entries in the run-time constant pool correspond directly to these structures. Some entries in the run-time constant pool are loadable, which means:

  • They may be pushed onto the stack by the ldc family of instructions (§ldc, §ldc_w, §ldc2_w).

  • They may be static arguments to bootstrap methods for dynamically-computed constants and call sites (§5.4.3.6). An entry in the run-time constant pool is loadable if it is derived from an entry in the constant_pool table that is loadable (see Table 4.4-C). Accordingly, the following entries in the run-time constant pool are loadable:

  • Symbolic references to classes and interfaces

  • Symbolic references to method handles

  • Symbolic references to method types

  • Symbolic references to dynamically-computed constants

  • Static constants

贡献翻译,请加 QQ: 840750575    点击这里给我发消息
数码
沪ICP备19006215号-4