Movatterモバイル変換

• byte, whose values are 8-bit signed two's-complement integers, and whose default value is zero

• short, whose values are 16-bit signed two's-complement integers, and whose default value is zero

• int, whose values are 32-bit signed two's-complement integers, and whose default value is zero

• long, whose values are 64-bit signed two's-complement integers, and whose default value is zero

• char, whose values are 16-bit unsigned integers representing Unicode code points in the Basic Multilingual Plane, encoded with UTF-16, and whose default value is the null code point ('\u0000')

• float, whose values are elements of the float value set or, where supported, the float-extended-exponent value set, and whose default value is positive zero

• double, whose values are elements of the double value set or, where supported, the double-extended-exponent value set, and whose default value is positive zero

The values of the integral types of the Java Virtual Machine are:

The floating-point types arefloat anddouble, which are conceptually associated with the 32-bit single-precision and 64-bit double-precision format IEEE 754 values and operations as specified inIEEE Standard for Binary Floating-Point Arithmetic (ANSI/IEEE Std. 754-1985, New York).

The IEEE 754 standard includes not only positive and negative sign-magnitude numbers, but also positive and negative zeros, positive and negativeinfinities, and a special Not-a-Number value (hereafter abbreviated as "NaN"). The NaN value is used to represent the result of certain invalid operations such as dividing zero by zero.

Every implementation of the Java Virtual Machine is required to support two standard sets of floating-point values, called thefloat value set and thedouble value set. In addition, an implementation of the Java Virtual Machine may, at its option, support either or both of two extended-exponent floating-point value sets, called thefloat-extended-exponent value set and thedouble-extended-exponent value set. These extended-exponent value sets may, under certain circumstances, be used instead of the standard value sets to represent the values of typefloat ordouble.

The finite nonzero values of any floating-point value set can all be expressed in the forms⋅m⋅ 2^{(e −N + 1)}, wheres is +1 or −1,m is a positive integer less than 2N, ande is an integer betweenE_min = −(2^K−1−2) andE_max = 2^K−1−1, inclusive, and whereN andK are parameters that depend on the value set. Some values can be represented in this form in more than one way; for example, supposing that a valuev in a value set might be represented in this form using certain values fors,m, ande, then if it happened thatm were even ande were less than 2^K-1, one could halvem and increasee by 1 to produce a second representation for the same valuev. A representation in this form is callednormalized ifm≥ 2^N-1; otherwise the representation is said to bedenormalized. If a value in a value set cannot be represented in such a way thatm≥ 2^N-1, then the value is said to be adenormalized value, because it has no normalized representation.

The constraints on the parametersN andK (and on the derived parametersE_min andE_max) for the two required and two optional floating-point value sets are summarized inTable 2.3.2-A.

Where one or both extended-exponent value sets are supported by an implementation, then for each supported extended-exponent value set there is a specific implementation-dependent constantK, whose value is constrained byTable 2.3.2-A; this valueK in turn dictates the values forE_min andE_max.

Each of the four value sets includes not only the finite nonzero values that are ascribed to it above, but also the five values positive zero, negative zero, positive infinity, negative infinity, and NaN.

Note that the constraints inTable 2.3.2-A are designed so that every element of the float value set is necessarily also an element of the float-extended-exponent value set, the double value set, and the double-extended-exponent value set. Likewise, each element of the double value set is necessarily also an element of the double-extended-exponent value set. Each extended-exponent value set has a larger range of exponent values than the corresponding standard value set, but does not have more precision.

The elements of the float value set are exactly the values that can be represented using the single floating-point format defined in the IEEE 754 standard, except that there is only one NaN value (IEEE 754 specifies 2²⁴-2 distinct NaN values). The elements of the double value set are exactly the values that can be represented using the double floating-point format defined in the IEEE 754 standard, except that there is only one NaN value (IEEE 754 specifies 2⁵³-2 distinct NaN values). Note, however, that the elements of the float-extended-exponent and double-extended-exponent value sets defined here donot correspond to the values that can be represented using IEEE 754 single extended and double extended formats, respectively. This specification does not mandate a specific representation for the values of the floating-point value sets except where floating-point values must be represented in theclass file format (§4.4.4,§4.4.5).

The float, float-extended-exponent, double, and double-extended-exponent value sets are not types. It is always correct for an implementation of the Java Virtual Machine to use an element of the float value set to represent a value of typefloat; however, it may be permissible in certain contexts for an implementation to use an element of the float-extended-exponent value set instead. Similarly, it is always correct for an implementation to use an element of the double value set to represent a value of typedouble; however, it may be permissible in certain contexts for an implementation to use an element of the double-extended-exponent value set instead.

Except for NaNs, values of the floating-point value sets areordered. When arranged from smallest to largest, they are negative infinity, negative finite values, positive and negative zero, positive finite values, and positive infinity.

Floating-point positive zero and floating-point negative zero compare as equal, but there are other operations that can distinguish them; for example, dividing1.0 by0.0 produces positive infinity, but dividing1.0 by-0.0 produces negative infinity.

NaNs areunordered, so numerical comparisons and tests for numerical equality have the valuefalse if either or both of their operands are NaN. In particular, a test for numerical equality of a value against itself has the valuefalse if and only if the value is NaN. A test for numerical inequality has the valuetrue if either operand is NaN.

ThereturnAddress type is used by the Java Virtual Machine'sjsr,ret, andjsr_w instructions (§jsr,§ret,§jsr_w). The values of thereturnAddress type are pointers to the opcodes of Java Virtual Machine instructions. Unlike the numeric primitive types, thereturnAddress type does not correspond to any Java programming language type and cannot be modified by the running program.

Although the Java Virtual Machine defines aboolean type, it only provides very limited support for it. There are no Java Virtual Machine instructions solely dedicated to operations onboolean values. Instead, expressions in the Java programming language that operate onboolean values are compiled to use values of the Java Virtual Machineint data type.

The Java Virtual Machine does directly supportboolean arrays. Itsnewarray instruction (§newarray) enables creation ofboolean arrays. Arrays of typeboolean are accessed and modified using thebyte array instructionsbaload andbastore (§baload,§bastore).

In Oracle’s Java Virtual Machine implementation,boolean arrays in the Java programming language are encoded as Java Virtual Machinebyte arrays, using 8 bits perboolean element.

The Java Virtual Machine encodesboolean array components using1 to representtrue and0 to representfalse. Where Java programming languageboolean values are mapped by compilers to values of Java Virtual Machine typeint, the compilers must use the same encoding.

The Java Virtual Machine can support many threads of execution at once (JLS §17). Each Java Virtual Machine thread has its ownpc (program counter) register. At any point, each Java Virtual Machine thread is executing the code of a single method, namely the current method (§2.6) for that thread. If that method is notnative, thepc register contains the address of the Java Virtual Machine instruction currently being executed. If the method currently being executed by the thread isnative, the value of the Java Virtual Machine'spc register is undefined. The Java Virtual Machine'spc register is wide enough to hold areturnAddress or a native pointer on the specific platform.

Each Java Virtual Machine thread has a privateJava Virtual Machine stack, created at the same time as the thread. A Java Virtual Machine stack stores frames (§2.6). A Java Virtual Machine stack is analogous to the stack of a conventional language such as C: it holds local variables and partial results, and plays a part in method invocation and return. Because the Java Virtual Machine stack is never manipulated directly except to push and pop frames, frames may be heap allocated. The memory for a Java Virtual Machine stack does not need to be contiguous.

In the First Edition ofTheJava® Virtual Machine Specification, the Java Virtual Machine stack was known as theJava stack.

This specification permits Java Virtual Machine stacks either to be of a fixed size or to dynamically expand and contract as required by the computation. If the Java Virtual Machine stacks are of a fixed size, the size of each Java Virtual Machine stack may be chosen independently when that stack is created.

A Java Virtual Machine implementation may provide the programmer or the user control over the initial size of Java Virtual Machine stacks, as well as, in the case of dynamically expanding or contracting Java Virtual Machine stacks, control over the maximum and minimum sizes.

The following exceptional conditions are associated with Java Virtual Machine stacks:

The Java Virtual Machine has aheap that is shared among all Java Virtual Machine threads. The heap is the run-time data area from which memory for all class instances and arrays is allocated.

The heap is created on virtual machine start-up. Heap storage for objects is reclaimed by an automatic storage management system (known as agarbage collector); objects are never explicitly deallocated. The Java Virtual Machine assumes no particular type of automatic storage management system, and the storage management technique may be chosen according to the implementor's system requirements. The heap may be of a fixed size or may be expanded as required by the computation and may be contracted if a larger heap becomes unnecessary. The memory for the heap does not need to be contiguous.

A Java Virtual Machine implementation may provide the programmer or the user control over the initial size of the heap, as well as, if the heap can be dynamically expanded or contracted, control over the maximum and minimum heap size.

The following exceptional condition is associated with the heap:

The Java Virtual Machine has amethod area that is shared among all Java Virtual Machine threads. The method area is analogous to the storage area for compiled code of a conventional language or analogous to the "text" segment in an operating system process. It stores per-class structures such as the run-time constant pool, field and method data, and the code for methods and constructors, including the special methods (§2.9) used in class and instance initialization and interface initialization.

The method area is created on virtual machine start-up. Although the method area is logically part of the heap, simple implementations may choose not to either garbage collect or compact it. This specification does not mandate the location of the method area or the policies used to manage compiled code. The method area may be of a fixed size or may be expanded as required by the computation and may be contracted if a larger method area becomes unnecessary. The memory for the method area does not need to be contiguous.

A Java Virtual Machine implementation may provide the programmer or the user control over the initial size of the method area, as well as, in the case of a varying-size method area, control over the maximum and minimum method area size.

The following exceptional condition is associated with the method area:

Arun-time constant pool is a per-class or per-interface run-time representation of theconstant_pool table in aclass file (§4.4). It contains several kinds of constants, ranging from numeric literals known at compile-time to method and field references that must be resolved at run-time. The run-time constant pool serves a function similar to that of a symbol table for a conventional programming language, although it contains a wider range of data than a typical symbol table.

Each run-time constant pool is allocated from the Java Virtual Machine's method area (§2.5.4). The run-time constant pool for a class or interface is constructed when the class or interface is created (§5.3) by the Java Virtual Machine.

The following exceptional condition is associated with the construction of the run-time constant pool for a class or interface:

See§5 (Loading, Linking, and Initializing) for information about the construction of the run-time constant pool.

An implementation of the Java Virtual Machine may use conventional stacks, colloquially called "C stacks," to supportnative methods (methods written in a language other than the Java programming language). Native method stacks may also be used by the implementation of an interpreter for the Java Virtual Machine's instruction set in a language such as C. Java Virtual Machine implementations that cannot loadnative methods and that do not themselves rely on conventional stacks need not supply native method stacks. If supplied, native method stacks are typically allocated per thread when each thread is created.

This specification permits native method stacks either to be of a fixed size or to dynamically expand and contract as required by the computation. If the native method stacks are of a fixed size, the size of each native method stack may be chosen independently when that stack is created.

A Java Virtual Machine implementation may provide the programmer or the user control over the initial size of the native method stacks, as well as, in the case of varying-size native method stacks, control over the maximum and minimum method stack sizes.

The following exceptional conditions are associated with native method stacks:

Each frame (§2.6) contains an array of variables known as itslocal variables. The length of the local variable array of a frame is determined at compile-time and supplied in the binary representation of a class or interface along with the code for the method associated with the frame (§4.7.3).

A single local variable can hold a value of typeboolean,byte,char,short,int,float,reference, orreturnAddress. A pair of local variables can hold a value of typelong ordouble.

Local variables are addressed by indexing. The index of the first local variable is zero. An integer is considered to be an index into the local variable array if and only if that integer is between zero and one less than the size of the local variable array.

A value of typelong or typedouble occupies two consecutive local variables. Such a value may only be addressed using the lesser index. For example, a value of typedouble stored in the local variable array at indexn actually occupies the local variables with indicesn andn+1; however, the local variable at indexn+1 cannot be loaded from. It can be stored into. However, doing so invalidates the contents of local variablen.

The Java Virtual Machine does not requiren to be even. In intuitive terms, values of typeslong anddouble need not be 64-bit aligned in the local variables array. Implementors are free to decide the appropriate way to represent such values using the two local variables reserved for the value.

The Java Virtual Machine uses local variables to pass parameters on method invocation. On class method invocation, any parameters are passed in consecutive local variables starting from local variable0. On instance method invocation, local variable0 is always used to pass a reference to the object on which the instance method is being invoked (this in the Java programming language). Any parameters are subsequently passed in consecutive local variables starting from local variable1.

Each frame (§2.6) contains a last-in-first-out (LIFO) stack known as itsoperand stack. The maximum depth of the operand stack of a frame is determined at compile-time and is supplied along with the code for the method associated with the frame (§4.7.3).

Where it is clear by context, we will sometimes refer to the operand stack of the current frame as simply the operand stack.

The operand stack is empty when the frame that contains it is created. The Java Virtual Machine supplies instructions to load constants or values from local variables or fields onto the operand stack. Other Java Virtual Machine instructions take operands from the operand stack, operate on them, and push the result back onto the operand stack. The operand stack is also used to prepare parameters to be passed to methods and to receive method results.

For example, theiadd instruction (§iadd) adds twoint values together. It requires that theint values to be added be the top two values of the operand stack, pushed there by previous instructions. Both of theint values are popped from the operand stack. They are added, and their sum is pushed back onto the operand stack. Subcomputations may be nested on the operand stack, resulting in values that can be used by the encompassing computation.

Each entry on the operand stack can hold a value of any Java Virtual Machine type, including a value of typelong or typedouble.

Values from the operand stack must be operated upon in ways appropriate to their types. It is not possible, for example, to push twoint values and subsequently treat them as along or to push twofloat values and subsequently add them with aniadd instruction. A small number of Java Virtual Machine instructions (thedup instructions (§dup) andswap (§swap)) operate on run-time data areas as raw values without regard to their specific types; these instructions are defined in such a way that they cannot be used to modify or break up individual values. These restrictions on operand stack manipulation are enforced throughclass file verification (§4.10).

At any point in time, an operand stack has an associated depth, where a value of typelong ordouble contributes two units to the depth and a value of any other type contributes one unit.

Each frame (§2.6) contains a reference to the run-time constant pool (§2.5.5) for the type of the current method to supportdynamic linking of the method code. Theclass file code for a method refers to methods to be invoked and variables to be accessed via symbolic references. Dynamic linking translates these symbolic method references into concrete method references, loading classes as necessary to resolve as-yet-undefined symbols, and translates variable accesses into appropriate offsets in storage structures associated with the run-time location of these variables.

This late binding of the methods and variables makes changes in other classes that a method uses less likely to break this code.

A method invocationcompletes normally if that invocation does not cause an exception (§2.10) to be thrown, either directly from the Java Virtual Machine or as a result of executing an explicitthrow statement. If the invocation of the current method completes normally, then a value may be returned to the invoking method. This occurs when the invoked method executes one of the return instructions (§2.11.8), the choice of which must be appropriate for the type of the value being returned (if any).

The current frame (§2.6) is used in this case to restore the state of the invoker, including its local variables and operand stack, with the program counter of the invoker appropriately incremented to skip past the method invocation instruction. Execution then continues normally in the invoking method's frame with the returned value (if any) pushed onto the operand stack of that frame.

A method invocationcompletes abruptly if execution of a Java Virtual Machine instruction within the method causes the Java Virtual Machine to throw an exception (§2.10), and that exception is not handled within the method. Execution of anathrow instruction (§athrow) also causes an exception to be explicitly thrown and, if the exception is not caught by the current method, results in abrupt method invocation completion. A method invocation that completes abruptly never returns a value to its invoker.

The key differences between the floating-point arithmetic supported by the Java Virtual Machine and the IEEE 754 standard are:

Every method has afloating-point mode, which is eitherFP-strict ornot FP-strict. The floating-point mode of a method is determined by the setting of theACC_STRICT flag of theaccess_flags item of themethod_info structure (§4.6) defining the method. A method for which this flag is set is FP-strict; otherwise, the method is not FP-strict.

Note that this mapping of theACC_STRICT flag implies that methods in classes compiled by a compiler in JDK release 1.1 or earlier are effectively not FP-strict.

We will refer to an operand stack as having a given floating-point mode when the method whose invocation created the frame containing the operand stack has that floating-point mode. Similarly, we will refer to a Java Virtual Machine instruction as having a given floating-point mode when the method containing that instruction has that floating-point mode.

If a float-extended-exponent value set is supported (§2.3.2), values of typefloat on an operand stack that is not FP-strict may range over that value set except where prohibited by value set conversion (§2.8.3). If a double-extended-exponent value set is supported (§2.3.2), values of typedouble on an operand stack that is not FP-strict may range over that value set except where prohibited by value set conversion.

In all other contexts, whether on the operand stack or elsewhere, and regardless of floating-point mode, floating-point values of typefloat anddouble may only range over the float value set and double value set, respectively. In particular, class and instance fields, array elements, local variables, and method parameters may only contain values drawn from the standard value sets.

An implementation of the Java Virtual Machine that supports an extended floating-point value set is permitted or required, under specified circumstances, to map a value of the associated floating-point type between the extended and the standard value sets. Such avalue set conversion is not a type conversion, but a mapping between the value sets associated with the same type.

Where value set conversion is indicated, an implementation is permitted to perform one of the following operations on a value:

In addition, where value set conversion is indicated, certain operations are required:

Such required value set conversions may occur as a result of passing a parameter of a floating-point type during method invocation, includingnative method invocation; returning a value of a floating-point type from a method that is not FP-strict to a method that is FP-strict; or storing a value of a floating-point type into a local variable, a field, or an array in a method that is not FP-strict.

Not all values from an extended-exponent value set can be mapped exactly to a value in the corresponding standard value set. If a value being mapped is too large to be represented exactly (its exponent is greater than that permitted by the standard value set), it is converted to a (positive or negative) infinity of the corresponding type. If a value being mapped is too small to be represented exactly (its exponent is smaller than that permitted by the standard value set), it is rounded to the nearest of a representable denormalized value or zero of the same sign.

Value set conversion preserves infinities and NaNs and cannot change the sign of the value being converted. Value set conversion has no effect on a value that is not of a floating-point type.

• It is declared in thejava.lang.invoke.MethodHandle class.

• It has a single formal parameter of typeObject[].

• It has a return type ofObject.

• It has theACC_VARARGS andACC_NATIVE flags set.

• Anathrow instruction (§athrow) was executed.

• An abnormal execution condition was synchronously detected by the Java Virtual Machine. These exceptions are not thrown at an arbitrary point in the program, but only synchronously after execution of an instruction that either:

  • Specifies the exception as a possible result, such as:

    • When the instruction embodies an operation that violates the semantics of the Java programming language, for example indexing outside the bounds of an array.

    • When an error occurs in loading or linking part of the program.

  • Causes some limit on a resource to be exceeded, for example when too much memory is used.

• An asynchronous exception occurred because:

  • Thestop method of classThread orThreadGroup was invoked, or

  • An internal error occurred in the Java Virtual Machine implementation.

  Thestop methods may be invoked by one thread to affect another thread or all the threads in a specified thread group. They are asynchronous because they may occur at any point in the execution of the other thread or threads. An internal error is considered asynchronous (§6.3).

Most of the instructions in the Java Virtual Machine instruction set encode type information about the operations they perform. For instance, theiload instruction (§iload) loads the contents of a local variable, which must be anint, onto the operand stack. Thefload instruction (§fload) does the same with afloat value. The two instructions may have identical implementations, but have distinct opcodes.

For the majority of typed instructions, the instruction type is represented explicitly in the opcode mnemonic by a letter:i for anint operation,l forlong,s forshort,b forbyte,c forchar,f forfloat,d fordouble, anda forreference. Some instructions for which the type is unambiguous do not have a type letter in their mnemonic. For instance,arraylength always operates on an object that is an array. Some instructions, such asgoto, an unconditional control transfer, do not operate on typed operands.

Given the Java Virtual Machine's one-byte opcode size, encoding types into opcodes places pressure on the design of its instruction set. If each typed instruction supported all of the Java Virtual Machine's run-time data types, there would be more instructions than could be represented in a byte. Instead, the instruction set of the Java Virtual Machine provides a reduced level of type support for certain operations. In other words, the instruction set is intentionally not orthogonal. Separate instructions can be used to convert between unsupported and supported data types as necessary.

Table 2.11.1-A summarizes the type support in the instruction set of the Java Virtual Machine. A specific instruction, with type information, is built by replacing theT in the instruction template in the opcode column by the letter in the type column. If the type column for some instruction template and type is blank, then no instruction exists supporting that type of operation. For instance, there is a load instruction for typeint,iload, but there is no load instruction for typebyte.

Note that most instructions inTable 2.11.1-A do not have forms for the integral typesbyte,char, andshort. None have forms for theboolean type. A compiler encodes loads of literal values of typesbyte andshort using Java Virtual Machine instructions that sign-extend those values to values of typeint at compile-time or run-time. Loads of literal values of typesboolean andchar are encoded using instructions that zero-extend the literal to a value of typeint at compile-time or run-time. Likewise, loads from arrays of values of typeboolean,byte,short, andchar are encoded using Java Virtual Machine instructions that sign-extend or zero-extend the values to values of typeint. Thus, most operations on values of actual typesboolean,byte,char, andshort are correctly performed by instructions operating on values of computational typeint.

The mapping between Java Virtual Machine actual types and Java Virtual Machine computational types is summarized byTable 2.11.1-B.

Certain Java Virtual Machine instructions such aspop andswap operate on the operand stack without regard to type; however, such instructions are constrained to use only on values of certain categories of computational types, also given inTable 2.11.1-B.

The load and store instructions transfer values between the local variables (§2.6.1) and the operand stack (§2.6.2) of a Java Virtual Machine frame (§2.6):

Instructions that access fields of objects and elements of arrays (§2.11.5) also transfer data to and from the operand stack.

Instruction mnemonics shown above with trailing letters between angle brackets (for instance,iload_<n>) denote families of instructions (with membersiload_0,iload_1,iload_2, andiload_3 in the case ofiload_<n>). Such families of instructions are specializations of an additional generic instruction (iload) that takes one operand. For the specialized instructions, the operand is implicit and does not need to be stored or fetched. The semantics are otherwise the same (iload_0 means the same thing asiload with the operand0). The letter between the angle brackets specifies the type of the implicit operand for that family of instructions: for<n>, a nonnegative integer; for<i>, anint; for<l>, along; for<f>, afloat; and for<d>, adouble. Forms for typeint are used in many cases to perform operations on values of typebyte,char, andshort (§2.11.1).

This notation for instruction families is used throughout this specification.

The arithmetic instructions compute a result that is typically a function of two values on the operand stack, pushing the result back on the operand stack. There are two main kinds of arithmetic instructions: those operating on integer values and those operating on floating-point values. Within each of these kinds, the arithmetic instructions are specialized to Java Virtual Machine numeric types. There is no direct support for integer arithmetic on values of thebyte,short, andchar types (§2.11.1), or for values of theboolean type; those operations are handled by instructions operating on typeint. Integer and floating-point instructions also differ in their behavior on overflow and divide-by-zero. The arithmetic instructions are as follows:

The semantics of the Java programming language operators on integer and floating-point values (JLS §4.2.2, JLS §4.2.4) are directly supported by the semantics of the Java Virtual Machine instruction set.

The Java Virtual Machine does not indicate overflow during operations on integer data types. The only integer operations that can throw an exception are the integer divide instructions (idiv andldiv) and the integer remainder instructions (irem andlrem), which throw anArithmeticException if the divisor is zero.

Java Virtual Machine operations on floating-point numbers behave as specified in IEEE 754. In particular, the Java Virtual Machine requires full support of IEEE 754denormalized floating-point numbers andgradual underflow, which make it easier to prove desirable properties of particular numerical algorithms.

The Java Virtual Machine requires that floating-point arithmetic behave as if every floating-point operator rounded its floating-point result to the result precision.Inexact results must be rounded to the representable value nearest to the infinitely precise result; if the two nearest representable values are equally near, the one having a least significant bit of zero is chosen. This is the IEEE 754 standard's default rounding mode, known asround to nearest mode.

The Java Virtual Machine uses the IEEE 754round towards zero mode when converting a floating-point value to an integer. This results in the number being truncated; any bits of the significand that represent the fractional part of the operand value are discarded. Round towards zero mode chooses as its result the type's value closest to, but no greater in magnitude than, the infinitely precise result.

The Java Virtual Machine's floating-point operators do not throw run-time exceptions (not to be confused with IEEE 754 floating-point exceptions). An operation that overflows produces a signed infinity, an operation that underflows produces a denormalized value or a signed zero, and an operation that has no mathematically definite result produces NaN. All numeric operations with NaN as an operand produce NaN as a result.

Comparisons on values of typelong (lcmp) perform a signed comparison. Comparisons on values of floating-point types (dcmpg,dcmpl,fcmpg,fcmpl) are performed using IEEE 754 nonsignaling comparisons.

The type conversion instructions allow conversion between Java Virtual Machine numeric types. These may be used to implement explicit conversions in user code or to mitigate the lack of orthogonality in the instruction set of the Java Virtual Machine.

The Java Virtual Machine directly supports the following widening numeric conversions:

The widening numeric conversion instructions arei2l,i2f,i2d,l2f,l2d, andf2d. The mnemonics for these opcodes are straightforward given the naming conventions for typed instructions and the punning use of 2 to mean "to." For instance, thei2d instruction converts anint value to adouble.

Most widening numeric conversions do not lose information about the overall magnitude of a numeric value. Indeed, conversions widening fromint tolong andint todouble do not lose any information at all; the numeric value is preserved exactly. Conversions widening fromfloat todouble that are FP-strict (§2.8.2) also preserve the numeric value exactly; only such conversions that are not FP-strict may lose information about the overall magnitude of the converted value.

Conversions fromint tofloat, or fromlong tofloat, or fromlong todouble, may loseprecision, that is, may lose some of the least significant bits of the value; the resulting floating-point value is a correctly rounded version of the integer value, using IEEE 754 round to nearest mode.

Despite the fact that loss of precision may occur, widening numeric conversions never cause the Java Virtual Machine to throw a run-time exception (not to be confused with an IEEE 754 floating-point exception).

A widening numeric conversion of anint to along simply sign-extends the two's-complement representation of theint value to fill the wider format. A widening numeric conversion of achar to an integral type zero-extends the representation of thechar value to fill the wider format.

Note that widening numeric conversions do not exist from integral typesbyte,char, andshort to typeint. As noted in§2.11.1, values of typebyte,char, andshort are internally widened to typeint, making these conversions implicit.

The Java Virtual Machine also directly supports the following narrowing numeric conversions:

The narrowing numeric conversion instructions arei2b,i2c,i2s,l2i,f2i,f2l,d2i,d2l, andd2f. A narrowing numeric conversion can result in a value of different sign, a different order of magnitude, or both; it may thereby lose precision.

A narrowing numeric conversion of anint orlong to an integral typeT simply discards all but then lowest-order bits, wheren is the number of bits used to represent typeT. This may cause the resulting value not to have the same sign as the input value.

In a narrowing numeric conversion of a floating-point value to an integral typeT, whereT is eitherint orlong, the floating-point value is converted as follows:

A narrowing numeric conversion fromdouble tofloat behaves in accordance with IEEE 754. The result is correctly rounded using IEEE 754 round to nearest mode. A value too small to be represented as afloat is converted to a positive or negative zero of typefloat; a value too large to be represented as afloat is converted to a positive or negative infinity. Adouble NaN is always converted to afloat NaN.

Despite the fact that overflow, underflow, or loss of precision may occur, narrowing conversions among numeric types never cause the Java Virtual Machine to throw a run-time exception (not to be confused with an IEEE 754 floating-point exception).

Although both class instances and arrays are objects, the Java Virtual Machine creates and manipulates class instances and arrays using distinct sets of instructions:

A number of instructions are provided for the direct manipulation of the operand stack:pop,pop2,dup,dup2,dup_x1,dup2_x1,dup_x2,dup2_x2,swap.

The control transfer instructions conditionally or unconditionally cause the Java Virtual Machine to continue execution with an instruction other than the one following the control transfer instruction. They are:

The Java Virtual Machine has distinct sets of instructions that conditionally branch on comparison with data ofint andreference types. It also has distinct conditional branch instructions that test for the null reference and thus it is not required to specify a concrete value fornull (§2.4).

Conditional branches on comparisons between data of typesboolean,byte,char, andshort are performed usingint comparison instructions (§2.11.1). A conditional branch on a comparison between data of typeslong,float, ordouble is initiated using an instruction that compares the data and produces anint result of the comparison (§2.11.3). A subsequentint comparison instruction tests this result and effects the conditional branch. Because of its emphasis onint comparisons, the Java Virtual Machine provides a rich complement of conditional branch instructions for typeint.

Allint conditional control transfer instructions perform signed comparisons.

The following five instructions invoke methods:

The method return instructions, which are distinguished by return type, areireturn (used to return values of typeboolean,byte,char,short, orint),lreturn,freturn,dreturn, andareturn. In addition, thereturn instruction is used to return from methods declared to be void, instance initialization methods, and class or interface initialization methods.

An exception is thrown programmatically using theathrow instruction. Exceptions can also be thrown by various Java Virtual Machine instructions if they detect an abnormal condition.

The Java Virtual Machine supports synchronization of both methods and sequences of instructions within a method by a single synchronization construct: themonitor.

Method-level synchronization is performed implicitly, as part of method invocation and return (§2.11.8). Asynchronized method is distinguished in the run-time constant pool'smethod_info structure (§4.6) by theACC_SYNCHRONIZED flag, which is checked by the method invocation instructions. When invoking a method for whichACC_SYNCHRONIZED is set, the executing thread enters a monitor, invokes the method itself, and exits the monitor whether the method invocation completes normally or abruptly. During the time the executing thread owns the monitor, no other thread may enter it. If an exception is thrown during invocation of thesynchronized method and thesynchronized method does not handle the exception, the monitor for the method is automatically exited before the exception is rethrown out of thesynchronized method.

Synchronization of sequences of instructions is typically used to encode thesynchronized block of the Java programming language. The Java Virtual Machine supplies themonitorenter andmonitorexit instructions to support such language constructs. Proper implementation ofsynchronized blocks requires cooperation from a compiler targeting the Java Virtual Machine (§3.14).

Structured locking is the situation when, during a method invocation, every exit on a given monitor matches a preceding entry on that monitor. Since there is no assurance that all code submitted to the Java Virtual Machine will perform structured locking, implementations of the Java Virtual Machine are permitted but not required to enforce both of the following two rules guaranteeing structured locking. LetT be a thread andM be a monitor. Then:

Note that the monitor entry and exit automatically performed by the Java Virtual Machine when invoking asynchronized method are considered to occur during the calling method's invocation.

• Reflection, such as the classes in the packagejava.lang.reflect and the classClass.

• Loading and creation of a class or interface. The most obvious example is the classClassLoader.

• Linking and initialization of a class or interface. The example classes cited above fall into this category as well.

• Security, such as the classes in the packagejava.security and other classes such asSecurityManager.

• Multithreading, such as the classThread.

• Weak references, such as the classes in the packagejava.lang.ref.

• Translating Java Virtual Machine code at load-time or during execution into the instruction set of another virtual machine.

• Translating Java Virtual Machine code at load-time or during execution into the native instruction set of the host CPU (sometimes referred to asjust-in-time, orJIT, code generation).