OPTIMIZING THE JAVA VIRTUAL MACHINE INSTRUCTION SET BY ...

101
machine code for the idioms. As a result, good performance can be achieved without
relying on optimizations performed by later optimization stages.
Before despecialization is performed, the bytecodes around the ifeq bytecode
in question match one of the idioms tested for by the virtual machine’s optimizer,
resulting in the generation of high quality machine code that represents those specific
bytecodes. After despecialization is performed no idiom is present to handle the
sequence of equivalent general purpose bytecodes. While the lack of an idiom to cover
the equivalent sequence of general purpose bytecodes may initially be expected to give
poorer performance, it leaves additional information for later optimization stages.
Ironically, it appears that removing ifeq and consequently avoiding a bytecode idiom
intended to result in the generation of high quality machine code is actually allowing
other optimizations to achieve a substantial performance gain.
Performance gains were also observed for a small number of benchmarks executed
using Sun virtual machines. These include three benchmarks executed using the Sun-
Blade 100 and one benchmark executed on the Pentium III. The performance gains
observed for the Sun virtual machines were much smaller than the change observed
for JGF LUFact on IBM’s RVM. Of the four benchmarks that showed improved performance
on a Sun virtual machine, the largest improvement was approximately nine
percent better than the original benchmark runtime. The source code for the Sun
virtual machines has not yet been examined. Consequently, it is not currently possible
to provide a detailed explanation of the performance improvements observed for
these benchmarks. However, as was the case for IBM’s RVM, it was often possible to
isolate the performance increase to a small number of despecializations. For example,
the performance gain achieved for the JGF Search benchmark was also present when
only the bytecodes lstore 2 and lload 2 were despecialized. Similarly, it was found
that despecializing only lconst 0 was able to achieve much of the performance gain
observed for the JGF Series benchmark. A small additional performance gain was
observed for this benchmark when both iconst 1 and lconst 0 were despecialized.
The final benchmark that showed a performance gain on the SunBlade 100 was
201 compress. Unlike the other benchmarks that showed a performance gain, this
benchmark showed gradually improving performance as the number of despecializations
increased rather than distinct jumps in performance when specific despecializations
were performed. As a result, it was not possible to isolate one or two specific
bytecodes that were responsible for the observed improvement in performance. A
similar situation also occurred for the JGF Series benchmark executed using Sun’s
virtual machine on a Pentium III. In this case, a performance gain was observed after