OPTIMIZING THE JAVA VIRTUAL MACHINE INSTRUCTION SET BY ...

114
The technique used by the Java virtual machine to pass the remainder of the
method parameters to the called scope also contributes to the difficulty of making
good selections for specialized load bytecodes. The analysis presented earlier in this
section came to the conclusion that the majority of the most frequently executed load
bytecodes are used to access programmer declared local variables rather than method
parameters. Because method parameters appear ahead of programmer declared variables
in the local variable slots it is impossible to select a small number of specialized
bytecodes that will work well for all methods. Selecting specialized values for the first
slots will work well in methods that take very few parameters. However methods that
take more parameters will be unable to utilize the specialized bytecodes effectively
because their parameters are already occupying those slots. Alternatively, specialized
bytecodes could be introduced for later slots instead of slots 0 through 3. While such
a system would work well for methods with several parameters and local variables,
methods with few parameters and local variables would be completely unable to use
the specialized bytecodes.
Consequently, when future virtual machines are designed and implemented, it is
recommended that their creators consider alternatives for accessing parameter values
in the called scope in order to facilitate more effective use of specialized bytecodes.
One option would be to have method parameters appear as the last local variables
rather than as the first local variables. Such a design decision would give compiler
writers considerably more freedom in ordering the local variables so as to make best
use of specialized bytecodes since the compiler would be free to assign those local
variables that are used the most to the slots for which specialized bytecodes exist.
In those methods without any programmer defined local variables the method parameters
would end up residing in the first slots in the local variable array, allowing
specialized bytecodes to be utilized in these methods as well.
Using a system where parameters occupy the last slots in the local variable array
would also permit the creation of alignment guidelines for category 2 data types.
Under such a system, specialized bytecodes for category 2 data types would only
exist for even numbered local variable slots. This system would make more effective
use of the category 2 loads because all specialized load bytecodes for a single data
type could be used within the same method. Under the current JVM design, it is
impossible for the specialized bytecodes dload 0 and dload 1 to reside within the
same method because each double value occupies 2 adjacent slots. Consequently,
while there are 4 specialized load bytecodes allocated for accessing variables with the
double data type, only half of them can be used in any given method.