OPTIMIZING THE JAVA VIRTUAL MACHINE INSTRUCTION SET BY ...

220
One option would be to treat multicodes as two byte opcodes while retaining single
byte opcodes for the bytecodes currently defined by the Java Virtual Machine
Specification. This could be accomplished in a manner similar to that employed by
the wide bytecode which is immediately followed by a second opcode specifying what
functionality should be performed in a wide manner. Unfortunately, this strategy increases
the amount of bytecode fetch overhead compared to implementing multicodes
in a manner identical to other bytecodes because a second decode operation must be
performed once it has been determined that the first byte in the two byte structure
indicates the presence of a multicode. However, if the length of the multicode is
greater than 2, the total number of decode operations being performed is still being
reduced compared to the original sequence.
A second option would be to use two byte opcodes for all bytecodes and multicodes.
In essence, this would change the structure of the class file from being bytecode
oriented to being short-code oriented. Those opcodes that require an odd number of
operand bytes would be padded so that the the number of operand bytes was always
even. As a result, the size of the code attribute would approximately double in size.
Adjusting the operands in this manner is not critical on Intel architectures because 2-
byte memory loads are permitted from any address. However, on architectures which
employ memory access alignment rules such as a Sun SPARC, padding operands in
this manner would be critical to the performance of the virtual machine. If operand
padding was not performed, it would be necessary for the low and high order halves of
the opcode to be loaded as separate single byte loads in order to meet the constraints
imposed by the architecture’s alignment rules. Failing to align loads correctly on a
SPARC results in a segmentation fault.
By employing either of these options, the total number of multicodes that can be
executed increases considerably. Under the first option, the number of multicodes
available would grow from 52 to over 13000. If the second option were implemented,
it would be possible to implement more than 65000 multicodes. However, given
the diminishing returns that are observed in all of the performance results, it is
unlikely that it would be worthwhile implementing this many multicodes for a single
application. Instead, allowing such a large number of multicodes to be implemented
would provide another technique for developing multicodes for many applications
without requiring multiple execution engines.