OPTIMIZING THE JAVA VIRTUAL MACHINE INSTRUCTION SET BY ...

115
Implementing alignment rules under the current system where method parameters
appear as the first local variables is also an option. However, it could lead to situations
where the specialized bytecodes go completely unutilized. Consider the case where
an instance method has 4 parameter of type double and the specialized bytecodes
for handling doubles are dload 0, dload 2, dload 4 and dload 6. In this example,
none of the specialized bytecodes would be used because the receiver object for the
method would occupy slot 0, causing the remaining parameters to reside in slots 1,
3, 5 and 7, requiring the dload bytecode to load or store the parameter values. This
problem could be partially resolved if the compiler intentionally introduced an empty
pad slot to align the values when necessary. However this still does not overcome
the problem of trying to decide what slots should have specialized bytecodes so as to
avoid specializing on method parameters while still encompassing the local variables
in all cases. Padding may also introduce a non-trivial amount of overhead for methods
that have a list of parameters that alternate between category 1 and category 2 types
since a padding slot would have to be introduced after every category 1 parameter in
order to align the following category 2 parameter with an even numbered slot.
A second alternative for improving specialized bytecode utilization would be to
completely separate the parameter values from the local variable array. Such a system
would require the introduction of new bytecodes dedicated to the task of accessing
method parameters. At a minimum this would require a pair of bytecodes similar
to getfield and putfield designed for accessing parameters. In practice, it may
be more desirable to include a series of typed parameter load and parameter store
instructions so as to avoid the overhead associated with resolving the types of method
parameters. Separating the local variables from the parameters in this manner would
give the compiler complete freedom in assigning programmer declared variables to
slots, allowing it to make the best possible use of the available specialized bytecodes
for accessing local variables.
The load bytecodes executed with least frequency were also considered. Initially
it was anticipated that this distribution would consist entirely of general purpose
bytecodes that executed extremely infrequently. However, this was not the case.
Figure 6.2 shows the distribution of the 40 least frequently executed load bytecodes.
This list includes 4 specialized bytecodes: lload 1, lload 2, fload 2 and
fload 0. The presence of any specialized bytecodes in this list is a serious concern.
In this specific case, 4 of the 40 worst possible choices for specialized bytecodes have
specialized bytecodes to represent them. It is also observed that all 4 of the specialized
bytecodes access values that are type float or type long. The presence of