JVM, Class Files, and the CLEmitter - Introduction to Compiler Construction in a Java World - page 318

4:iload_3
5:ireturn
Here is how the JVM executes this code.
The iload_1 instruction loads the integer value at offset 1 (for x ) onto the stack at
frame offset 4.
The next iload_2 instruction loads the integer value at offset 2 (for y ) onto the stack
at frame offset 5.
The iadd instruction pops the two integers of the top of the stack (from frame offsets
4 and 5), adds them using integer addition, and then pushes the result ( x+y ) back
onto the stack at frame offset 4.
The istore_3 instruction pops the top value (at frame offset 4) off the stack and
stores it at offset 3 (for z ).
The iload_3 instruction loads the value at frame offset 3 (for z ) onto the stack at
frame offset 4.
Finally, the ireturn instruction pops the top integer value from the stack (at frame
location 4), pops the stack frame from the stack, and returns control to the invoking
method, pushing the returned value onto the invoking method's frame.
Notice that the instruction set takes advantage of common offsets within the stack frame.
For example, the iload_1 instruction is really shorthand for iload1 .
The iload_1 instruction occupies just one byte for the opcode; the opcode for iload_1
is 27. But the other version requires two bytes: one for the opcode (21) and one byte for
the operand's oset (1). The JVM is trading opcode space|a byte may only represent up
to 256 dierent operations|to save code space.
A frame may be extended to contain additional implementation-specific data such as
the information required to support a run-time debugger.
D.2.3 Heap
Objects are represented on the stack as pointers into the heap, which is shared among all
JVM threads. The heap is the run-time data area from which memory for all class instances
and arrays is allocated. It is created during the JVM start-up. Heap storage for objects is
reclaimed by an automatic storage management system called the garbage collector.
D.2.4 Method Area
The JVM has a method area that is shared among all JVM threads. It is created during the
JVM start-up. 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
used in class and instance initialization and interface type initialization.
D.2.5 Run-Time Constant Pool
The run-time constant pool is a per-class or per-interface run-time representation of the
constant_pool table in a class file. 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. It is constructed when the class or interface is created by the JVM.