VM Spec

Contents | Prev | Next | Index | The JavaTM Virtual Machine Specification

A B C D F G I J L M N P R S T W

## monitorenter

Operation

> Enter monitor for object

Format

> monitorenter

Forms

> monitorenter = 194 (0xc2)

Operand Stack

> ..., objectref ...

Description

> The objectref must be of type `reference`.

> Each object has a monitor associated with it. The thread that executes monitorenter gains ownership of the monitor associated with objectref. If another thread already owns the monitor associated with objectref, the current thread waits until the object is unlocked, then tries again to gain ownership. If the current thread already owns the monitor associated with objectref, it increments a counter in the monitor indicating the number of times this thread has entered the monitor. If the monitor associated with objectref is not owned by any thread, the current thread becomes the owner of the monitor, setting the entry count of this monitor to 1.

Runtime Exception

> If objectref is `null`, monitorenter throws a `NullPointerException`.

Notes

> For detailed information about threads and monitors in the Java virtual machine, see Chapter 8, "Threads and Locks."

> A monitorenter instruction may be used with one or more monitorexit instructions to implement a `synchronized` statement in the Java programming language. The monitorenter and monitorexit instructions are not used in the implementation of `synchronized` methods, although they can be used to provide equivalent locking semantics; however, monitor entry on invocation of a `synchronized` method is handled implicitly by the Java virtual machine's method invocation instructions. See Section 7.14 for more information on the use of the monitorenter and monitorexit instructions.

> The association of a monitor with an object may be managed in various ways that are beyond the scope of this specification. For instance, the monitor may be allocated and deallocated at the same time as the object. Alternatively, it may be dynamically allocated at the time when a thread attempts to gain exclusive access to the object and freed at some later time when no thread remains in the monitor for the object.

> The synchronization constructs of the Java programming language require support for operations on monitors besides entry and exit. These include waiting on a monitor (`Object.wait`) and notifying other threads waiting on a monitor (`Object.notifyAll` and `Object.notify`). These operations are supported in the standard package `java.lang` supplied with the Java virtual machine. No explicit support for these operations appears in the instruction set of the Java virtual machine.

## monitorexit

Operation

> Exit monitor for object

Format

> monitorexit

Forms

> monitorexit = 195 (0xc3)

Operand Stack

> ..., objectref ...

Description

> The objectref must be of type `reference`.

> The current thread should be the owner of the monitor associated with the instance referenced by objectref. The thread decrements the counter indicating the number of times it has entered this monitor. If as a result the value of the counter becomes zero, the current thread releases the monitor. If the monitor associated with objectref becomes free, other threads that are waiting to acquire that monitor are allowed to attempt to do so.

Runtime Exceptions

> If objectref is `null`, monitorexit throws a `NullPointerException`.

> Otherwise, if the current thread is not the owner of the monitor, monitorexit throws an `IllegalMonitorStateException`.

> Otherwise, if the virtual machine implementation enforces the rules on structured use of locks described in Section 8.13 and if the second of those rules is violated by the execution of this monitorexit instruction, then monitorexit throws an `IllegalMonitorStateException`.

Notes

> For detailed information about threads and monitors in the Java virtual machine, see Chapter 8, "Threads and Locks."

> One or more monitorexit instructions may be used with a monitorenter instruction to implement a `synchronized` statement in the Java programming language. The monitorenter and monitorexit instructions are not used in the implementation of `synchronized` methods, although they can be used to provide equivalent locking semantics.

> The Java virtual machine supports exceptions thrown within `synchronized` methods and `synchronized` statements differently. Monitor exit on normal `synchronized` method completion is handled by the Java virtual machine's return instructions. Monitor exit on abrupt `synchronized` method completion is handled implicitly by the Java virtual machine's athrow instruction. When an exception is thrown from within a `synchronized` statement, exit from the monitor entered prior to the execution of the `synchronized` statement is achieved using the Java virtual machine's exception handling mechanism. See Section 7.14 for more information on the use of the monitorenter and monitorexit instructions.

## multianewarray

Operation

> Create new multidimensional array

Format

> multianewarray
> indexbyte1
> indexbyte2
> dimensions

Forms

> multianewarray = 197 (0xc5)

Operand Stack

> ..., count1, [count2, ...] ..., arrayref

Description

> The dimensions operand is an unsigned byte that must be greater than or equal to 1. It represents the number of dimensions of the array to be created. The operand stack must contain dimensions values. Each such value represents the number of components in a dimension of the array to be created, must be of type `int`, and must be nonnegative. The count1 is the desired length in the first dimension, count2 in the second, etc.

> All of the count values are popped off the operand stack. The unsigned indexbyte1 and indexbyte2 are used to construct an index into the runtime constant pool of the current class (§3.6), where the value of the index is (indexbyte1 << 8) | indexbyte2. The runtime constant pool item at the index must be a symbolic reference to a class, array, or interface type. The named class, array, or interface type is resolved (§5.4.3.1). The resulting entry must be an array class type of dimensionality greater than or equal to dimensions.

> A new multidimensional array of the array type is allocated from the garbage-collected heap. If any count value is zero, no subsequent dimensions are allocated. The components of the array in the first dimension are initialized to subarrays of the type of the second dimension, and so on. The components of the last allocated dimension of the array are initialized to the default initial value for the type of the components (§2.5.1). A `reference` arrayref to the new array is pushed onto the operand stack.

Linking Exceptions

> During resolution of the symbolic reference to the class, array, or interface type, any of the exceptions documented in Section 5.4.3.1 can be thrown.

> Otherwise, if the current class does not have permission to access the element type of the resolved array class, multianewarray throws an `IllegalAccessError`.

Runtime Exception

> Otherwise, if any of the dimensions values on the operand stack are less than zero, the multianewarray instruction throws a `Negative` `ArraySizeException`.

Notes

> It may be more efficient to use newarray or anewarray when creating an array of a single dimension.

> The array class referenced via the runtime constant pool may have more dimensions than the dimensions operand of the multianewarray instruction. In that case, only the first dimensions of the dimensions of the array are created.

Contents | Prev | Next | Index

The JavaTM Virtual Machine Specification
Copyright © 1999 Sun Microsystems, Inc. All rights reserved
Please send any comments or corrections to jvm@java.sun.com