Flow‐sensitive runtime estimation: an enhanced hot spot detection heuristics for embedded Java just‐in‐time compilers

Abstract

Java just-in-time compilers often compile only hot methods because the compilation overhead is a part of the running time. This requires precise and efficient hot spot detection, which includes distinguishing hot methods from cold ones, detecting them as early as possible, and paying a small detection overhead. Hot spot detection is especially important in embedded applications because they show more of a start-up phase behavior of a regular application where methods are not executed heavily, so the hot methods are not definite. Because a long-running method is likely to be a hot method, we can detect a hot method by measuring its running time during interpretation. However, precise measurement of the running time during execution is too expensive, especially in embedded systems, so many counter-based heuristics have been proposed to estimate it such as Oracle's HotSpot heuristic. One problem is that although the overhead of these heuristics is low, they do not estimate the running time precisely, which may lead to imprecise hot spot detection.This paper proposes a new hot spot detection heuristic called flow-sensitive runtime estimation, which can estimate the running time more precisely than others with a relatively low overhead. It only counts important bytecode instructions dynamically, but it can obtain the precise count of all interpreted bytecode instructions with a simple arithmetic calculation. We also propose a static analysis technique to predict those hot methods which spends a huge execution time once invoked, so as to compile them at their first invocation. Our experimental results show that these techniques can improve the performance by as much as an average of 7.4% compared with the HotSpot heuristic for the benchmarks when they run once, which is often regarded as showing the start-up phase behavior. Even for real embedded Java applications such as the digital TV Java Xlet applications, our techniques can improve the user response time by an average of 7.1%. bytecode into machine code have been employed, such as just-in-time compilers (JITCs) [3]. JITC performs the translation at runtime, often on a method-by-method basis (Some JITC translates only hot portions of a method [4], but we assume a method-based JITC in this paper).Because the translation overhead is a part of the running time, most JITCs employ adaptive compilation, where a method is interpreted or compiled by the baseline compiler initially and then is compiled with optimizations only when it is found to be hot [5]. The method can be compiled again with more optimizations if it is found to be really hot [6]. This requires precise and efficient hot spot detection. Generally, hot spot detection in the middle of execution is a difficult problem. A method detected as a hot spot can easily become a cold spot because we cannot know its future behavior. Also, hot spots should be detected early because even a long-running method cannot lead to a performance improvement if detected and compiled too late, while a short-running method can be a...