Efficient Exception Handling in Java Bytecode-to-C Ahead-of-Time Compiler for Embedded

Computer Languages, Systems and Structures Volume 34 , Issue 4 (December 2008) Pages: 170-183One of the most promising approaches to Java acceleration in embedded systems is a bytecode-to-C ahead-of-time compiler (AOTC). It improves the performance of a Java virtual machine (JVM) by translating bytecode into C code, which is then compiled into machine code via an existing C compiler. One important design issue in AOTC is efficient exception handling. Since the excepting point and the exception handler may locate in different methods on a call stack, control transfer between them should be streamlined, while an exception would be an ''exceptional'' event, so it should not slow down normal execution paths. Previous AOTCs often employed a technique called stack cutting based on a setjmp()/longjmp() pair, which we found is involved with too much performance overheads. Also, when the AOTC and the interpreter are employed concurrently (e.g., some methods are AOTCed while other methods are interpreted), the performance of normal execution paths is affected more seriously. This paper proposes a simpler solution based on an exception check after each method call, merged with garbage collection check for reducing its overhead. Our evaluation results on SPECjvm98 on Sun's CVM indicate that our technique can improve the performance of stack cutting by more than 25%. A similar performance benefit can be noted on a hybrid execution environment of both the AOTC and the interpreter

Program Transformations for Light-Weight CPU Accounting and Control in the Java Virtual Machine - A Systematic Review

This article constitutes a thorough presentation of an original scheme for portable CPU accounting and control in Java, which is based on program transformation techniques at the bytecode level and can be used with every standard Java Virtual Machine. In our approach applications, middleware, and even the standard Java runtime libraries (i.e., the Java Development Kit) are modified in a fully portable way, in order to expose details regarding the execution of threads. These transformations however incur a certain overhead at runtime. Further contributions of this article are the systematic review of the origin of such overheads and the description of a new static path prediction scheme targeted at reducing them

Platform-independent profiling in a virtual execution environment

Virtual execution environments, such as the Java virtual machine, promote platform-independent software development. However, when it comes to analyzing algorithm complexity and performance bottlenecks, available tools focus on platform-specific metrics, such as the CPU time consumption on a particular system. Other drawbacks of many prevailing profiling tools are high overhead, significant measurement perturbation, as well as reduced portability of profiling tools, which are often implemented in platform-dependent native code. This article presents a novel profiling approach, which is entirely based on program transformation techniques, in order to build a profiling data structure that provides calling-context-sensitive program execution statistics. We explore the use of platform-independent profiling metrics in order to make the instrumentation entirely portable and to generate reproducible profiles. We implemented these ideas within a Java-based profiling tool called JP. A significant novelty is that this tool achieves complete bytecode coverage by statically instrumenting the core runtime libraries and dynamically instrumenting the rest of the code. JP provides a small and flexible API to write customized profiling agents in pure Java, which are periodically activated to process the collected profiling information. Performance measurements point out that, despite the presence of dynamic instrumentation, JP causes significantly less overhead than a prevailing tool for the profiling of Java code

내장형 시스템에서 Just-in-Time 및 Ahead-of-Time 컴파일을 활용한 하이브리드 자바 컴파일

학위논문 (박사)-- 서울대학교 대학원 : 전기·컴퓨터공학부, 2015. 8. 문수묵.Many embedded Java software platforms execute two types of Java classes: those installed statically on the client device and those downloaded dynamically from service providers at runtime. For higher performance, it would be desirable to compile static Java classes by ahead-of-time compiler (AOTC) and to handle dynamically downloaded classes by just-in-time compiler (JITC), providing a hybrid compilation environment. We propose a hybrid Java compilation approach and performs an initial case study with a hybrid environment, which is constructed simply by merging an existing AOTC and a JITC for the same JVM. Contrary to our expectations, the hybrid environment does not deliver a performance, in-between of full-JITCs and full-AOTCs. In fact, its performance is even lower than full-JITCs for many benchmarks. We analyzed the result and found that a naive merge of JITC and AOTC may result in inefficiencies, especially due to calls between JITC methods and AOTC methods. We also observed that the distribution of JITC methods and AOTC methods is also important, and experimented with various distributions to understand when a hybrid environment can deliver a desired performance. The Android Java is to be executed by the Dalvik virtual machine (VM), which is quite different from the traditional Java VM such as Oracles HotSpot VM. That is, Dalvik employs register-based bytecode while HotSpot employs stack-based bytecode, requiring a different way of interpretation. Also, Dalvik uses trace-based just-in-time compilation (JITC), while HotSpot uses method-based JITC. Therefore, it is questioned how the Dalvik VM performs compared the HotSpot VM. Unfortunately, there has been little comparative evaluation of both VMs, so the performance of the Dalvik VM is not well understood. More importantly, it is also not well understood how the performance of the Dalvik VM affects the overall performance of the Android applications (apps). We make an attempt to evaluate the Dalvik VM. We install both VMs on the same board and compare the performance using EEMBC benchmark. In the JITC mode, Dakvik is slower than HotSpot by more than 2.9 times and its generated code size is not smaller than HotSpots due to its worse code quality and trace-chaining code. We also investigated how real Android apps are different from Java benchmarks, to understand why the slow Dalvik VM does not affect the performance of the Android apps seriously. We proposes a bytecode-to-C ahead-of-time compilation (AOTC) for the DVM to accelerate pre-installed apps. We translated the bytecode of some of the hot methods used by these apps to C code, which is then compiled together with the DVM source code. AOTC-generated code works with the existing Android zygote mechanism, with correct garbage collection and exception handling. Due to off-line, method-based compilation using existing compiler with full optimizations and Java-specific optimizations, AOTC can generate quality code while obviating runtime compilation overhead. For benchmarks, AOTC can improve the performance by 65%. When we compare with the recently-introduced ART, which also performs ahead-of-time compilation, our AOTC performs better. We cannot AOTC all middleware and framework methods in DTV and android device for hybrid compilation. By case study on DTV, we found that we need to adopt AOTC enough methods and reduce method call overhead. We propose AOTC method selection heuristic using method call chain. We select hot methods and call chain methods using profile data. Our heuristic based on method call chain get better performance than other heuristics.Chapter 1 Introduction 1 1.1 The need of hybrid compilation 1 1.2 Outline of the Dissertation 2 Chapter 2 Hybrid Compilation for Java Virtual Machine 3 2.1 The Approach of Hybrid Compilation 3 2.2 The JITC and AOTC 6 2.2.1 JVM and the Interpreter 7 2.2.2 The JITC 8 2.2.3 The AOTC 9 2.3 Hybrid Compilation Environment 11 2.4 Analysis of the Hybrid Environment 14 2.4.1 Call Behavior of Benchmarks 14 2.4.2 Call Overhead 15 2.4.3 Application Methods and Library Methods 18 2.4.4 Improving hybrid performance 20 2.4.4.1 Reducing the JITC-to-AOTC call overhead 20 2.4.4.2 Performance impact of the distribution of JITC methods and AOTC methods 21 Chapter 3 Evaluation of Dalvik Virtual Machine 23 3.1 Android Platform 23 3.2 Java VM and Dalvik VM 24 3.2.1 Bytecode ISA 25 3.2.3 Just-in-Time Compilation (JITC) 27 3.3 Experimental Results 32 3.3.1 Experimental Environment 33 3.3.2 Interpreter Performance 34 3.3.3 JITC Performance 37 3.3.4 Trace Extension 43 3.4 Behavior of Real Android Apps 44 Chapter 4 Ahead-of-Time Compilation for Dalvik Virtual Machine 51 4.1 Android and Dalvik VM Execution 51 4.1.1 Android Execution Model 51 4.1.2 Dalvik VM 51 4.1.3 Dexopt and JITC in the Dalvik VM 53 4.2 AOTC Architecture 54 4.3 Design and Implementation of AOTC 56 4.3.1 Dexopt and Code Generation 56 4.3.2 C Code Generation 56 4.3.3 AOTC Method Call 58 4.3.4 Garbage Collection 61 4.3.5 Exception Handling 62 4.3.6 AOTC Method Linking 63 4.4 AOTC Code Optimization 64 4.4.1 Method Inlining 64 4.4.2 Spill Optimization 64 4.4.3 Elimination of Redundant Code 65 4.5 Experimental Result 65 4.5.1 Experimental Environment 66 4.5.2 AOTC Target Methods 66 4.5.3 Performance Impact of AOTC 67 4.5.4 DVM AOTC vs. ART 68 Chapter 5 Selecting Ahead-of-Time Compilation Target Methods for Hybrid Compilation 70 5.1 Hybrid Compilation on DTV 70 5.2 Hybrid Compilation on Android Device 72 5.3 AOTC for Hybrid Compilation 74 5.3.1 AOTC Target Methods 74 5.3.2 Case Study: Selecting on DTV 75 5.4 Method Selection Using Call Chain 77 5.5 Experimental Result 77 5.5.1 Experimental Environment 78 5.5.2 Performance Impact 79 Chapter 6 Related Works 81 Chapter 7 Conclusion 84 Bibliography 86Docto

A Study of Exception Handling and Its Dynamic Optimization in Java

Optimizing exception handling is critical for programs that frequently throw exceptions. We observed that there are many such exception-intensive programs in various categories of Java programs. There are two commonly used exception handling techniques, stack unwinding and stack cutting. Stack unwinding optimizes the normal path, while stack cutting optimizes the exception handling path. However, there has been no single exception handling technique to optimize both paths. We propose a new technique called Exception-Directed Optimization (Edo), which optimizes exception-intensive programs without slowing down exception-minimal programs. Edo, a feedback-directed dynamic optimization, consists of three steps, exception path profiling, exception path inlining, and throw elimination. Exception path profiling attempts to detect hot exception paths. Exception path inlining compiles the catching method in a hot exception path, inlining the rest of methods in the path. Throw elimination replaces a throw with the explicit control flow to the corresponding catch. We implemented Edo in IBM's production Justin -Time compiler, and obtained the experimental results, which show that, in SPECjvm98, it improved performance of exception-intensive programs by up to 18.3% without affecting performance of exception-minimal programs at all

A study of exception handling and its dynamic optimization in Java

Optimizing exception handling is critical for programs that frequently throw exceptions. We observed that there are many such exception-intensive programs in various categories of Java programs. There are two commonly used exception handling techniques, stack unwinding and stack cutting. Stack unwinding optimizes the normal path, while stack cutting optimizes the exception handling path. However, there has been no single exception handling technique to optimize both paths. We propose a new technique called Exception-Directed Optimization (Edo), which optimizes exception-intensive programs without slowing down exception-minimal programs. Edo, a feedbackdirected dynamic optimization, consists of three steps, exception path profiling, exception path inlining, and throw elimination. Exception path profiling attempts to detect hot exception paths. Exception path inlining compiles the catching method in a hot exception path, inlining the rest of methods in the path. Throw elimination replaces a throw with the explicit control flow to the corresponding catch. We implemented Edo in IBM’s production Justin-Time compiler, and obtained the experimental results, which show that, in SPECjvm98, it improved performance of exceptionintensive programs by up to 18.3 % without affecting performance of exception-minimal programs at all