OPTIMIZING THE JAVA VIRTUAL MACHINE INSTRUCTION SET BY ...

100
interruption was less than two percent of the original benchmark runtime. While
these interruptions were reproduced each time the benchmark was tested, their small
magnitude makes them relatively uninteresting.
The fact that any of the benchmarks showed performance characteristics that
resided in the third group (improved performance as the number of despecializations
increased) was a surprising result. The result that was most shocking was the performance
of JGF LUFact when it was executed using IBM’s RVM on a Pentium 4. A
large reduction in execution performance was observed when 48 or more despecializations
were performed. Performing further tests revealed that the performance gain
of approximately 42 percent could be attributed to the despecialization of the ifeq
bytecode.
Further work was conducted in order to isolate which occurrences of ifeq were
responsible for the change in performance. This involved despecializing groups of
class files until the change in performance was observed. No change in performance
was observed when all occurrences of ifeq were removed from the class files in the
Java library. The change in performance was observed when the original library
class files were employed in conjunction with despecialized benchmark application
files. Despecializing progressively smaller sets of the benchmark’s class files eventually
resulted in the determination of the fact that despecializing only one class file was
responsible for the change in performance. Furthermore, by despecializing only some
of the occurrences of ifeq within that file, it was determined that exactly one static
occurrence of ifeq was responsible for the observed performance increase.
Examining IBM’s RVM revealed that this change in performance is the result of
an unexpected interaction between the bytecode sequence present after despecialization
is performed and the virtual machine’s optimizing compiler. When IBM’s virtual
machine performs JIT compilation it may make use of either its baseline compiler or
its optimizing compiler. The baseline compiler is used initially, quickly generating
machine code that is far from optimal. This translation process is performed on a
per-bytecode basis with no time spent trying to optimize any interactions present
between adjacent bytecodes. When the virtual machine recognizes that a particular
method is executed with great frequency, the method is recompiled using the optimizing
compiler which generates machine code that is generally of much higher quality
than the code generated by the baseline compiler. One technique employed by the
optimizing compiler involves performing pattern matching on the bytecode stream.
This technique, referred to as bytecode idiom matching, identifies sequences of bytecodes
that are found to occur commonly and automatically generates high quality