OPTIMIZING THE JAVA VIRTUAL MACHINE INSTRUCTION SET BY ...

113
function being integrated. Because the method to perform this task is an instance
method, accessing its first parameter (the position at which to compute the value of
the function) results in the use of a dload 1 bytecode rather than a dload 0. Had the
JGF Series benchmark been removed from consideration, both dload 0 and dload 1
would have dropped out of the top 40 most frequently executed load bytecodes.
The preceding analysis leads to the conclusions that many specialized load bytecodes
are not being utilized effectively. This suggests that a new set of specialized
load bytecodes could be selected which would be executed with greater frequency.
Ideally, the distribution of these specialized bytecodes would include those local variable
positions and data types that are being used with greatest frequency. While the
current selection of specialized load bytecodes has a level of symmetry to it that is
appealing to many people because it offers identical coverage for all data types, it is
not reflective of the reality of the bytecodes executed by Java applications. For example,
no float or long loads are present in the list of 40 most frequently executed load
bytecodes while half of the list consists of integer loads. Loads of double precision
floating point values and object references account for the other half of the 40 most
frequently executed load bytecodes. Reallocating many of the float and long loads
to cover additional integer locations would shrink class file size and could improve
virtual machine performance.
In addition to suggesting changes to the distribution of specialized bytecodes based
on data type, the absence of any loads for the float and long data types in the top
40 specialized bytecodes suggests that optimizers may not want to spend the time
necessary to perform complex optimizations on these data types. Since the bytecodes
that access these data types are executed infrequently, any performance gains achieved
from these optimizations would need to be vast in comparison to the gains achieved
for integers, object references or double precisions floating point numbers.
It was also observed that the design of the Java Virtual Machine greatly restricts
the ability of the compiler to make use of the specialized bytecodes that access slot 0.
The Java Virtual Machine specification requires that the receiver object be passed as
the first parameter to all virtual methods. A direct consequence of this design choice
is the fact that the specialized bytecodes dload 0, fload 0, iload 0 and lload 0 can
never be executed in a virtual method since slot 0 is already occupied by the receiver
object. While it was observed that the JGF Series benchmark makes effective use
of the dload 0 bytecode, most applications make heavy use of instance methods,
preventing them from making effective use of these bytecodes during much of their
execution.