Maintenance Review of JSR 924 (JavaTM Virtual Machine Specification) for Java SE 7
Last updated 2011-04-15 by Alex Buckley
The clarifications and amendments below are proposed to the Java Virtual Machine Specification, Second Edition. They build on the clarifications and amendments for Java SE 5.0 made by the first Maintenance Review of JSR 924. They incorporate changes proposed for Java SE 6 by the second Maintenance Review of JSR 924.
The complete amended specification is the Java Virtual Machine Specification, Java SE 7 Edition. (The next edition of the Java Language Specification will also be known as the Java SE 7 Edition.)
Clarifications and Amendments to the Java Virtual Machine Specification, Second Edition
Compliance with JSR 901 (The Java Language Specification)
In the Java Virtual Machine Specification, Second Edition, it was the case that Chapter 2, "Java Programming Language Concepts", incorporated significant amounts of text from the First Edition of Java Language Specification. Rather than incorporating text from a more recent edition of the Java Language Specification into Chapter 2, the authors decided that the Java Virtual Machine Specification should cross-reference the Java Language Specification where necessary, though as little as possible. The out-of-date body of Chapter 2 has been removed.
The cross-references imply no material change in the Java Virtual Machine Specification. In particular, Section 4.3, "The Internal Form of Names", and Section 5.1, "The Runtime Constant Pool", use binary names (JLS 13.1) rather than qualified names, which reflects the behavior of the JVM Reference Implementation.
Chapter 3, "The Structure of the Java Virtual Machine", is renumbered to be chapter 2. Definitions for array types and default values are added to sections 2.3 and 2.4.
Chapter 7, "Compiling for the Java Virtual Machine", is renumbered to be chapter 3. (While "Compiling for the Java Virtual Machine" is non-normative, it is an interesting topic that usefully follows the instruction set overview at the end of "The Structure of the Java Virtual Machine".)
Compliance with JSR 133 (Java Memory Model)
Chapter 8, "Threads and Locks", is superceded by JSR 133. The out-of-date body of Chapter 8 has been removed, in accordance with the Maintenance Review of JSR 924 for Java SE 5.0.
Terminology for monitors in Chapter 6, "The Java Virtual Machine Instruction Set", and for structured locking in Section 2.11.10 (formerly 3.11.10), "Synchronization", has been made consistent with JSR 133 by uniformly discussing entry and exit of monitors.
Compliance with JSR 202 (Java Class File Specification Update)
Chapter 4, "The class File Format", describes verification by
The Prolog rule for a type-safe exception handler has been modified to
incorporate knowledge of the single
The rule for
The rule for
The specification of two containers of type information in
Compliance with dynamic linking in JVM implementations
A linking step that previously failed may now be repeated provided
it did not fail with a
The JVM throws a
The initialization procedure for a class or interface relaxes the
requirement to lock on the user-visible
The initialization procedure for a class or interface is more aggressive about initializing the values of constant fields in the class or interface. Rather than happening as part of the class or interface initialization method in step 9, constant value assignment now occurs in step 6, before superclass initialization. This rule reflects the behavior of the JVM Reference Implementation.
Section 5.4.2, "Preparation", clarifies that a loader constraint is never formed from an array type, but rather from the element type of an array type. The same concern applies to loader constraint generation during resolution in sections 22.214.171.124, 126.96.36.199, and 188.8.131.52. This reflects the behavior of the JVM Reference Implementation.
Section 4.3.4, "Signatures", clarifies the role and definition of
Section 4.7, "Attributes", specifies the
Section 4.7.6, "The
Section 4.7.8, "The Synthetic Attribute", clarifies that
Section 4.7.11, "The SourceDebugExtension Attribute", clarifies that
Sections 4.7.21 and 4.7.22 document the
Incorrect statements about the treatment of components of boolean
arrays by the
The linking and runtime exceptions for the
A normative reference to Unicode 6.0.0 has been added, and Unicode
terminology has been clarified (2.3, 4.2, 4.3, 4.4, 5.1). Notably, the
term "character" has been replaced with "code point". Notice that both
The Java Naming and Versioning rules are followed throughout.
Sections have been moved or reworded to clarify synchronization (2.11.10 (formerly 3.11.10), 3.15 (formerly 7.15)), linking errors (5.4) and virtual machine errors (6.3).
Section 3.14 (formerly 7.14), "Synchronization", shows the
contemporary output of
Section 3.15 (formerly 7.15), "Annotations", specifies the
structure of a
Further Clarifications and Amendments to the Java Virtual Machine Specification, Second Edition
A number of comments were received on the proposed text of the Java Virtual Machine Specification, Java SE 7 Edition during a Maintenance Review in February/March 2011. Further amendments to the text are made, below, as a result of these comments.
4.7.4 "The StackMapTable Attribute" says "If a method's Code attribute
does not have a StackMapTable attribute, it has an implicit stack map
attribute." This clause will be noted as applicable only when the Code
attribute is in a
4.9.2 "Structural Constraints" says "There must never be an uninitialized class instance on the operand stack or in a local variable when any backwards branch is taken." This is too strong because there can be an uninitialized class type in the model operand stack/variable array at the target of a backward branch, provided the same uninitialized class type occurred in the same location in the model at the source of the branch. (This is noted in 184.108.40.206 "Instance Initialization Methods and Newly Created Objects", per CR 6594979.) Since an uninitialized class type can only ever be type-merged with itself, any branch is safe w.r.t. uninitialized class types in the source and target models; hence, the 4.9.2 clause will be removed.
5.3 "Creation and Loading" says "If a user-defined classloader prefetches binary representations of classes and interfaces, or loads a group of related classes together, then it must reflect loading errors only at points in the program where they could have arisen without prefetching or group loading." While this appears to be a new constraint on user-defined loaders, the behavior of a class loader has never been arbitrary. JLS3 12.2 states two invariants for a well-behaved loader, and a loader must also respect the general principle of the Java virtual machine that "Errors detected during linkage are thrown at a point in the program where some action is taken by the program that might, directly or indirectly, require linkage to the class or interface involved in the error." This principle gives rise to the invariant about prefetching. For clarity, invariants for a user-defined class loader have been centralized in 5.3, using the word "should" rather than "must" to indicate that a JVM implementation is not expected to enforce them.
220.127.116.11 "Method overriding" embodies the definition of overriding proposed in the clarifications and amendments for Java SE 5.0 made by the first Maintenance Review of JSR 924. (The proposal was in line with a global change from many years earlier, that made overriding a transitive relation.) As such, the definition is simply a restatement of the definition in the Java Language Specification with generics artifacts removed.
5.5 "Initialization" says "For each class or interface C, there is a unique initialization lock LC. The mapping from C to LC is left to the discretion of the Java virtual machine implementation." This clause will be expanded to exemplify that LC can be the Class object for C, or the monitor associated with that object.
5.7 "Virtual Machine Exit" makes statements that assume the JNI Invocation API is used to load and unload the JVM. Use of this API is not mandatory. The section will be changed to specify that JVM exit can be controlled by certain Java SE API calls, and that JNI may further be used to terminate the JVM.