OPTIMIZING THE JAVA VIRTUAL MACHINE INSTRUCTION SET BY ...

102
16 despecializations were performed. However, the gain appears to be the cumulative
result of the combination of several despecializations, making it difficult to isolate
exactly which combination of despecializations is of benefit.
In general, the performance gains achieved through despecializations are relatively
minor and occur only for a small number of benchmarks. Consequently it is not generally
recommended that despecialization be used as a technique for attempting to
improve application performance. Instead, it is simply observed that Java virtual
machines are complex systems and that subtle interactions between different parts
of that system, including the selection of Java bytecodes and the optimizations performed
at various stages can have unanticipated results.
The final sub-category covers those benchmarks that showed irregular performance
with no apparent trend as the number of despecializations performed increased. Of
these benchmarks, three showed a single large spike in performance that was subsequently
overcome, returning to a runtime similar to the baseline performance, by
performing additional despecializations. In at least some cases, this behaviour appears
to be the result of performing ‘one half’ of a pair of despecializations, without
performing the despecialization on the bytecode’s mate. For example, when 48 despecializations
were performed several specialized istore bytecodes have been removed
including istore 1, istore 2 and istore 3. However, the corresponding specialized
load bytecodes have not yet been despecialized because they were executed with
greater frequency. This may cause the optimizer difficulty when optimizations are performed
on a sequence of bytecodes where local variables must be loaded and stored
to the same local variable positions because the loads will be performed with specialized
bytecodes while the stores are performed with general purpose bytecodes.
Consequently, the optimizer may fail to recognize that the sequence is a candidate for
such optimizations. The final 2 benchmarks in this group show additional variability
rather than a single larger spike in performance. It is believed that their performance
is also the result of an interaction between the bytecodes selected and the virtual
machine’s optimizer.
5.2.5 Performance Summary
The average performance change across all virtual machines is presented for each
benchmark in Figure 5.1. This figure also includes the overall average change in performance
across all benchmarks, virtual machines and computer architectures tested.
Overall, the average performance change observed when 32 or fewer despecializations