Dong-Heon Jung

Hybrid compilation and optimization for java-based digital TV platforms

The Java-based software platform for interactive digital TV (DTV) is composed of the system/middleware class statically installed on the DTV set-top box and the xlet applications dynamically downloaded from the TV stations. The xlet application includes Java classes and image/text files. The xlets are executed only when the TV viewer initiates an interaction, even if the xlets have been completely downloaded. To achieve high performance on this dual-component, user-initiated system, existing just-in-time (JIT) compilation and optimization is not enough; instead, ahead-of-time and idle-time compilation and optimization are also needed, requiring a hybrid compilation and optimization environment. We constructed such a hybrid environment for a commercial DTV software platform and evaluated it using real, on-air xlet applications. Our experimental results show that the proposed hybrid environment can improve the DTV Java performance by more than three times, compared to the JIT-only environment, with little change to other DTV behavior.

Hybrid Java compilation and optimization for digital TV software platform

The Java software platform for the interactive digital TV (DTV) is composed of the system/middleware classes statically installed on the DTV set-top box and the xlet classes dynamically downloaded from the TV stations, where xlets are executed only when the TV viewer initiates the interaction. In order to achieve high performance on this dual-component, user-initiated system, existing just-in-time compilation is not enough, but idle-time compilation and optimization as well as ahead-of-time compilation are also needed, requiring a hybrid compilation and optimization environment. We constructed such a hybrid environment for a commercial DTV software platform and experimented with real, on-air xlet applications. Our experimental results show that the proposed hybrid environment can improve the DTV Java performance by as much as an average of 150%, compared to the JITC-only environment.

Supporting precise garbage collection in Java Bytecode-to-C ahead-of-time compiler for embedded systems

A Java bytecode-to-C ahead-of-time compiler (AOTC) can improve 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. Although AOTC is effective in embedded Java systems, a bytecode-to-C AOTC could not easily employ precise garbage collection (GC) due to a difficulty in making a GC map, which keeps information on where each root live object is located when GC occurs. This is one of the reasons why all previous JVMs using a bytecode-to-C AOTC employed conservative GC, which can lead to poorer GC performance with more frequent memory shortage, especially in embedded systems where memory is tight.In this paper, we propose a way of allowing precise GC in a bytecode-to-C AOTC by generating additional C code which collects GC map-equivalent information at runtime. In order to reduce this runtime overhead, we also propose two optimization techniques which remove unnecessary C code. Our experimental results on Suns CVM indicate that we can support precise GC for bytecode-to-C AOTC with a relatively low overhead.

Evaluation of a Java Ahead-of-Time Compiler for Embedded Systems†

Java embedded systems often include Java middleware classes installed on the client device. For higher performance, they can be compiled into machine code before runtime using an ahead-of-time compiler (AOTC). There are many approaches to AOTC, yet a bytecode-to-C (b-to-C) AOTC which translates the bytecode into the C code and then compiles it using an existing optimizing compiler such as gcc would be the most straightforward one. This paper explores a few important design and optimization issues of a b-to-C AOTC, including the compilation form for the translated C code, the call interfaces among translated and interpreted Java methods, and Java-specific optimizations by the AOTC that can complement the gcc optimizations. We evaluate these issues with our b-to-C AOTC implemented on the MIPS platform for the Suns CDC VM to understand their performance impact.

Design and Optimization of a Java Ahead-of-Time Compiler for Embedded Systems

Most embedded Java software platforms include a Java middleware installed on the client device. It can be optimized using the ahead-of-time compiler (AOTC), which translates the Java bytecode into the machine code before runtime. There are many approaches to AOTC, but a bytecode-to-C AOTC which translates the bytecode into C code and then compile it using an existing optimizing compiler such as gcc would be a practical one. This paper explores a few important design and optimization issues of a bytecode-to-C AOTC, including the compilation strategy for the translated C code, the call interfaces between Java methods, and Java-specific optimizations by the AOTC that can complement the gcc optimizations. We evaluate these issues with a bytecode-to-C AOTC to understand their performance impact.

HYBRID JAVA COMPILATION OF JUST-IN-TIME AND AHEAD-OF TIME FOR EMBEDDED SYSTEMS

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. This paper proposes 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 Java virtual machine. Both compilers are developed independently for their own performance advantages with a generally accepted approach of compilation, but we merged them as efficiently as possible. 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 benchmark...