OPTIMIZING THE JAVA VIRTUAL MACHINE INSTRUCTION SET BY ...

95
when a pure interpreter virtual machine was used to execute the benchmarks.
Despecialization resulted in a greater average performance loss on
this platform than any other. Consequently, while despecialization has a
minimal impact once JIT compilation is performed, slower run times can
be expected for the portion of the code executed before JIT compilation
occurs. However, it is worth noting that the amount of time spent executing
the application with the interpreter is typically far less than the
amount of time spent executing code generated by the JIT compiler.
The infrequency with which some specialized bytecodes were executed was initially
a surprising result because it was assumed that the specialized bytecodes that
are defined by the Java Virtual Machine Specification were selected for some sound
reason. However, looking to the architecture of the Java Virtual Machine revealed
that design decisions made about the architecture of the Java Virtual Machine cause
some specialized bytecodes to execute infrequently.
Four Java bytecodes are defined which have the ability to change the flow of control
within the application to a new method. These bytecodes include invokevirtual,
invokestatic, invokeinterface and invokespecial. In this document, they are
referred to collectively as the invoke* bytecodes. In each case, the arguments passed
to the method being invoked must be present on the operand stack before the necessary
invoke* bytecode is executed. When an invoke* bytecode is encountered, the
arguments are copied from the operand stack in the calling scope and placed into
local variables in the called scope. The first argument is placed in local variable slot
0, the second argument is placed in local variable slot 1, and so on. When a value
of type long or double is passed as a parameter, it occupies two slots in the local
variable array.
The bytecodes iload 0, fload 2 and dload 3 are specialized versions of the general
purpose bytecodes iload, fload and dload respectively. The inclusion of these
specialized forms in the Java Virtual Machine Specification implies that accesses to
the first four local variable slots are more common than accesses to slots with greater
indices. However, in many cases, parameter values (other than the receiver object)
are read only once at the start of the method and then are never used again. This
is because local variables defined within the method are used to hold temporary results
generated during the computation rather than overwriting the parameter value.
Unfortunately programmer declared local variables are often unable to make use of
specialized bytecodes for loads and stores because the slots for which specialized load
and store bytecodes exist have already been occupied by method parameters.