Bytecode fetch optimization for a Java interpreter

  • Authors:
  • Kazunori Ogata;Hideaki Komatsu;Toshio Nakatani

  • Affiliations:
  • IBM Tokyo Research Laboratory, Yamato-shi, Kanagawa, Japan;IBM Tokyo Research Laboratory, Yamato-shi, Kanagawa, Japan;IBM Tokyo Research Laboratory, Yamato-shi, Kanagawa, Japan

  • Venue:
  • Proceedings of the 10th international conference on Architectural support for programming languages and operating systems
  • Year:
  • 2002

Quantified Score

Hi-index 0.00

Visualization

Abstract

Interpreters play an important role in many languages, and their performance is critical particularly for the popular language Java. The performance of the interpreter is important even for high-performance virtual machines that employ just-in-time compiler technology, because there are advantages in delaying the start of compilation and in reducing the number of the target methods to be compiled. Many techniques have been proposed to improve the performance of various interpreters, but none of them has fully addressed the issues of minimizing redundant memory accesses and the overhead of indirect branches inherent to interpreters running on superscalar processors. These issues are especially serious for Java because each bytecode is typically one or a few bytes long and the execution routine for each bytecode is also short due to the low-level, stack-based semantics of Java bytecode. In this paper, we describe three novel techniques of our Java bytecode interpreter, write-through top-of-stack caching (WT), position-based handler customization (PHC), and position-based speculative decoding (PSD), which ameliorate these problems for the PowerPC processors. We show how each technique contributes to improving the overall performance of the interpreter for major Java benchmark programs on an IBM POWER3 processor. Among three, PHC is the most effective one. We also show that the main source of memory accesses is due to bytecode fetches and that PHC successfully eliminates the majority of them, while it keeps the instruction cache miss ratios small.