Debugging optimized code with dynamic deoptimization
PLDI '92 Proceedings of the ACM SIGPLAN 1992 conference on Programming language design and implementation
A portable sampling-based profiler for Java virtual machines
Proceedings of the ACM 2000 conference on Java Grande
Adaptive optimization in the Jalapeño JVM
OOPSLA '00 Proceedings of the 15th ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications
The Java Language Specification
The Java Language Specification
The simplest heuristics may be the best in Java JIT compilers
ACM SIGPLAN Notices
Design, implementation and evaluation of adaptive recompilation with on-stack replacement
Proceedings of the international symposium on Code generation and optimization: feedback-directed and runtime optimization
A brief history of just-in-time
ACM Computing Surveys (CSUR)
When and what to compile/optimize in a virtual machine?
ACM SIGPLAN Notices
The java hotspotTM server compiler
JVM'01 Proceedings of the 2001 Symposium on JavaTM Virtual Machine Research and Technology Symposium - Volume 1
Selective just-in-time compilation for client-side mobile javascript engine
CASES '11 Proceedings of the 14th international conference on Compilers, architectures and synthesis for embedded systems
| Hi-index | 0.00 |
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. This paper proposes a new hot spot detection heuristic which can estimate the running time more precisely than others with a relatively low overhead. It dynamically counts only important bytecodes interpreted, but with a simple arithmetic calculation it can obtain the precise count of all interpreted bytecodes. We also propose employing a static analysis technique to predict those hot methods which spend a huge execution time once invoked. This static prediction can allow compiling these methods at their first-invocation, complementing the proposed dynamic estimation technique. We implemented both, which led to a performance benefit of 10% compared to the HotSpot heuristic.