Summary 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 efficienthot 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 calledflow‐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 ofallinterpreted 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%. Copyright © 2015 John Wiley & Sons, Ltd.

The discussion on how to effectively program embedded systems has often in the past revolved around issues like the ideal instruction set architecture (ISA) or the best operating system. Much of this has been motivated by the inherently resource-constrained nature of embedded devices that mandates efficiency as the primary design principle.

Smart phone's full web browsing requires a high-performance JavaScript engine because JavaScript execution takes a non-trivial portion of the loading time for many web sites. The current wisdom of speeding up JavaScript engine is simply turning on its just-in-time compilation (JITC), which compiles JavaScript code to machine code on the fly and executes it instead of interpretation. Unfortunately, we found that JITC actually increases the loading time tangibly for some JavaScript-heavy web pages compared to interpretation, while it can still reduce the running time for JavaScript benchmarks. We observed that the web page JavaScript behaves differently from the benchmark JavaScript in the sense that hot spots rarely exist. This would lower the reuse ratio of the compiled machine code, making the compilation overhead higher than its benefit. This is especially true for a JavaScript engine which compiles all executed functions at their first invocation, as the SFX engine in the WebKit. In order to overcome this problem, we introduce selective compilation to the SFX engine so as to compile only hot functions detected during interpretation. This reduces the slowdown of the SFX for web page JavaScript, while accelerating JavaScript benchmarks. However, selective compilation for web page JavaScript shows a different behavior from other environment, and we discuss it.

Most Java just-in-time compilers (JITC) try to compile only hot methods since the compilation overhead is part of the running time. This requires precise and efficient hot spot detection, which includes distinguishing hot methods from cold methods, detecting them as early as possible, and paying a small runtime overhead for detection. A hot method could be identified by measuring its running time during interpretation since a long-running method is likely to be a hot method. 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. The Simple heuristic counts only method invocations without any consideration of loops [1], while Sun's HotSpot heuristic counts loop iterations as well, but does not consider loop sizes or method sizes [2,14]. The static analysis heuristic estimates the running time of a method by statically analyzing loops or heavy-cost bytecodes but does not measure their dynamic counts [3]. Although the overhead of these heuristics is low, they do not estimate the running time precisely, which may lead to imprecise hot spot detection.

Up to now, the power problems which could be caused by the huge amount of hardware resources present in modern systems have not been a primary concern. More recently, however, power consumption has begun limiting the number of resources which can be safely integrated into a single package, lest the heat dissipation exceed physical limits (before actual package meltdown). At the same time, new architectural techniques such as simultaneous multithreading (SMT), whose goal it is to efficiently use the resources of a superscalar machine without introducing excessive additional control overhead, have appeared on the scene. In this paper, we present a new resource management scheme which enables an efficient low power mode in SMT architectures. The proposed scheme is based on a modified pipeline throttling technique which introduces a throttling point at the last stage of the processor pipeline in order to reduce power consumption. We demonstrate that resource utilization plays an important role in efficient power management and that our strategy can significantly improve performance in the power-saving mode. Since the proposed resource management scheme tests the processor condition cycle by cycle, we evaluate its performance by setting a target IPC as one sort of immediate power measure. Our analysis shows that an SMT processor with our dynamic resource management scheme can yield significantly higher overall performance