OPTIMIZING THE JAVA VIRTUAL MACHINE INSTRUCTION SET BY ...

181
7.9 Conclusion
This chapter has introduced an optimization strategy that has come to be known as
multicode substitution. It employs profiling in order to identify sequences of bytecodes
that are executed with great frequency. Once those sequences are identified,
a new multicode is introduced for each sequence. This multicode provides identical
functionality to the bytecode sequence it replaces but makes use of only a single
opcode.
The process of fetching and decoding bytecodes is a large source of overhead
within a Java interpreter. A variety of bytecode dispatch techniques can be employed
including a simple loop and switch statement or more advanced strategies such as
threading. Performing the multicode substitution reduces the fetch and decode operations
performed regardless of the bytecode dispatch strategy employed, resulting in
improved application performance.
Performance results were generated for six of the benchmarks in the SPEC JVM98
benchmark suite. The amount of performance benefit achieved varied. In the worst
case, only minor gains in performance were achieved with application run time being
reduced to approximately 96 percent of the original run time. However, other
benchmarks showed much better performance. Using only the number of transfers
removed in order to identify bytecode sequences for multicode replacement resulted in
application run times that were 76 percent of the original run time for 201 compress
and 73 percent of the original run time for 222 mpegaudio.
When multicode substitution is performed, new optimization opportunities become
available that could not be exploited previously due to the presence of the
intervening transfers of control. Some of these optimizations are performed automatically
while others require knowledge about the behaviour of the virtual machine
which is not known by the compiler. Using a timing based multicode selection strategy
that included the impact of these optimizations in the multicode selection process
resulted in application run times that were less than 70 percent of the original run
time for the 222 mpegaudio benchmark.