Java VMs for Embedded Systems

One important characteristic of Java is portability, which means that the compiled binary code of Java classes should be executable on any JRE systems regardless of its underlying hardware or OS platforms and producing exactly the same behaviors. This is achieved by compiling the Java language programs to the intermediate codes called Java bytecodes. Java bytecode instructions are analogous to machine codes, but usually are executed by a virtual machine (VM) written specifically for the host hardware. End-user will use a JRE installed on the target device for Java applications. To make clear distinction among various Java devices, Sun Microsystems develops three different JRE, Java Platform, Enterprise Edition (Java EE), Java Platform, Standard Edition (Java SE), and Java Platform, Micro Edition (Java ME). Java ME was formerly known as Java 2 Platform, Micro Edition (J2ME)[9]. J2ME is designed specifically for embedded systems. Target devices range from industrial controllers to mobile phones and set-top boxes. Furthermore, the J2ME has been divided into two base configurations, one to fit small mobile devices and one to target towards more capable devices like smart-phones and set top boxes. The configuration for small devices is called the Connected Limited Device Configuration (CLDC) [10] and the more capable configuration is called the Connected Device Configuration (CDC) [11].

Traditional JRE is composed of a Java Virtual Machine (JVM) [14] and a set of standard class libraries. The software-based Java VM is implemented on non-virtual hardware and on standard operating systems. JVM adopts stack architecture and its

organization is shown in Fig. 2. In the Java virtual machine specification, the three major components are the class loader subsystem, the runtime data area, and the execution engine [7]. The class loader is a mechanism for loading classes or interfaces given fully qualified names. The runtime data area is the major memory space that the Java VM organizes to execute a program. The execution engine is another mechanism that is responsible for executing the instructions contained in the methods of loaded classes. More details of the Java class file format is described in the VM specification [14].

Fig. 2. The block diagram of Java virtual machine.

The Java VM will interpret and execute the Java bytecodes at runtime. However, implementing a stack-based virtual machine using an interpreter has a great impact on the performance, especially for the embedded processors. The interpreters are slow (up to an order of magnitude slowdown) and require memory to store the interpreter code. In addition, many operations are expensive for embedded processors, such as simulation of a stack-machine, dynamic symbol resolutions, and heavy dynamic memory allocations. Therefore, there are many performance and memory constraint issues for embedded systems with a regular processor. The solutions for improving

class files Class Loader

Subsystem

Method

Area Heap Java

stacks

Native method

stacks Runtime Data Area

Execution Engine

Native Method Interface

Native method lib.

PC Registers

the time and space overhead of JRE can be roughly divided into three approaches.

The Just-in-Time (JIT) compilers, the hardware-based co-processors (e.g. ARM Jazelle), and sand-alone Java processors (e.g. picoJava) are common measures for embedded environments.

The execution speed improves significantly by using JIT compilation techniques [16] [17] to translate Java bytecodes to native codes at runtime. Although, the speedup by the JIT compiler is high, JIT requires extra memory [17] and imposes extra compilation overhead for class loading. The compiler itself along with the memory footprint for the compilation may require a few megabytes of storage [16]. Therefore, this approach is less suitable for embedded devices, which have strong memory constraints. An interesting effort is taken on by Google when picking a solution for their Android application environment. The Dalvik VM [8] is a register-based virtual machine which is not binary compatible with the JVM. Java application class files must be converted into Dex file format before execution. It is shown that a register-based VM can be 32.3% more efficient than a stack-based VM when executing standard benchmarks by an interpreter, at the expense of 25% larger binary code size of the benchmark programs [20].

It is important to point out that, the implementation of most JRE heavily relies on the underlying operating system. However, most Java middleware stacks of JREs have already included main functions of a typical operating system. Therefore, adopting a complete operating system underneath a JRE is a duplication of system functions, which is not a good design philosophy for embedded devices with resource constraints.

Building a purely hardwired Java processor is a nontrivial task, as the Java VM instruction set is quite complex. Some instructions are even more complex than

the instructions of a traditional CISC CPU such as the Intel x86 and Motorola 680x0 families. There are several Java processor solutions such as picoJava [22], Komodo [23], jHISC [24], and JOP [25]. Because the processor is custom-designed to match the stack machine model of the JVM, it can deliver better bytecode execution performance than that of a general-purpose processor running a Java interpreter.

However, a single core stack machine designed to support Java complex low-level communication and multimedia controls may not be the most proper architecture for JRE. After all, many communication and multimedia tasks can be executed more efficiently using traditional register-based processor architecture.

The final approach is the Java co-processors approach used in, for example, ARM Jazelle [15]. These proposals use improved stack machines to execute the Java bytecodes and used resister-based processor to handle other tasks. Unfortunately, such architectures are tied to specific processor architecture and are not generally available for other host processors.