jvm 2

2.4 Reference Types and Values

There are three kinds of reference types: class types, array types, and interface types. 

Their values are references to dynamically created class instances, arrays, or class instances or arrays that implement interfaces, respectively.
An array type consists of a class instances or arrays that implement interfaces, respectively.

An array type consists of a component type with a single dimension (whose length  is not given by the type). 

The component type of an array type may itself be an array type. 

If, starting from any array type, one considers its component type, and then (if that is also an array type) the component type of that type, and so on, eventually one must reach a component type that is not an array type; 

this is called the element type of the array type. 

The element type of an array type is necessarily either a primitive type, or a class type, or an interface type.

A reference value may also be the special null reference, a reference to no object,

which will be denoted here by null. The null reference initially has no run-time type, but may be cast to any type. 

The default value of a reference type is null.
The Java Virtual Machine specification does not mandate a concrete value encoding

The Java Virtual Machine specification does not mandate a concrete value encoding null.

2.5 Run-Time Data Areas
The Java Virtual Machine defines various run-time data areas that are used during
execution of a program. Some of these data areas are created on Java Virtual
Machine start-up and are destroyed only when the Java Virtual Machine exits.
Other data areas are per thread. Per-thread data areas are created when a thread is
created and destroyed when the thread exits.
2.5.1 The pc Register
The Java Virtual Machine can support many threads of execution at once (JLS
§17). Each Java Virtual Machine thread has its own pc (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 not
native, the pc register contains the address of the Java Virtual Machine instruction
currently being executed. If the method currently being executed by the thread is
native, the value of the Java Virtual Machine's pc register is undefined. The Java
Virtual Machine's pc register is wide enough to hold a returnAddress or a native
pointer on the specific platform.
2.5.2 Java Virtual Machine Stacks
Each Java Virtual Machine thread has a private Java 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 Java Virtual Machine Specification, First Edition, the Java Virtual Machine stack
was known as the Java 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:
• If the computation in a thread requires a larger Java Virtual Machine stack than
is permitted, the Java Virtual Machine throws a StackOverflowError.
• If Java Virtual Machine stacks can be dynamically expanded, and expansion is
attempted but insufficient memory can be made available to effect the expansion,
or if insufficient memory can be made available to create the initial Java Virtual Machine stack for a new thread, 

the Java Virtual Machine throws an OutOfMemoryError.

2.5.3 Heap
The Java Virtual Machine has a heap 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 a garbage 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:
• If a computation requires more heap than can be made available by the
automatic storage management system, the Java Virtual Machine throws an OutOfMemoryError.