REAL-TIME JAVA FOR EMBEDDED DEVICES: THE JAVAMEN PROJECT* A. Borg, N. Audsley, A. Wellings The University of York, UK ABSTRACT: Hardware Java-specific processors have been shown to provide the performance benefits over their software counterparts that make Java a feasible environment for executing even the most computationally expensive systems. In most cases, the core of these processors is a simple stack machine on which stack operations and logic and arithmetic operations are carried out. More complex bytecodes are implemented either in microcode through a sequence of stack and memory operations or in Java and therefore through a set of bytecodes. This paper investigates the Figure 1: Three alternatives for executing Java code (take from (6)) state-of-the-art in Java processors and identifies two areas of improvement for specialising these processors timeliness as a key issue. The language therefore fails to for real-time applications. This is achieved through a allow more advanced temporal requirements of threads combination of the implementation of real-time Java to be expressed and virtual machine implementations components in hardware and by using application- may behave unpredictably in this context. For example, specific characteristics expressed at the Java level to whereas a basic thread priority can be specified, it is not drive a co-design strategy. An implementation of these required to be observed by a virtual machine and there propositions will provide a flexible Ravenscar- is no guarantee that the highest priority thread will compliant virtual machine that provides better preempt lower priority threads. In order to address this performance while still guaranteeing real-time shortcoming, two competing specifications have been requirements. introduced: the “Real-Time Core Extensions” from the J-Consortium (3) and the ``Real-Time Specification for 1. INTRODUCTION Java'' (RTSJ) (4) from Sun Microsystems. The former has not achieved the exposure of the RTSJ, though The Java programming model has become established attempts are now being made to combine the two in mainstream software development as a platform for standards for a safety-critical Java (5). general-purpose applications. The abstraction provided by the virtual machine realises the attractive Write- The Java Virtual Machine specification describes an Once-Run-Anywhere (WORA) concept. Initially abstract stack machine that executes byte-code, the created for developing software for consumer devices, it intermediate code of the Java language. The achieved its success in the rapid expansion of the implementation of this abstraction could be handled Internet for which the WORA concept found an ideal either as a middleware application on top of stock application. Today, Java is penetrating into more niche hardware and operating systems or by a direct hardware markets, from large enterprise applications to small implementation. The tradeoff between these two embedded devices such as mobile phones. In particular, approaches is one of cost and speed; hardware the Micro Edition of the Java 2 Platform (J2ME) implementations are fast but could be expensive. As provides an application development environment that with any programming language, Java code could be specifically addresses the needs of embedded devices compiled down to native code unique to a particular 1 such as personal digital assistants and set-top boxes. platform, thereby deriving a performance benefit at the cost of portability and a significantly larger code size. Despite this new focus on embedded devices, J2ME and This latter overhead occurs because the runtime the Java superset do not address the application domain semantics must be embedded in application code. These of real-time applications. Indeed, until recently, “Java” three approaches are depicted in Figure (1) as described and “real-time” were considered an oxymoron as Java in (6) for the picoJava processor. The majority of lacked the infrastructure to enable development of real- current deployments of Java virtual machine time systems. The specifications of both Language (1) implementations are of the first type. Even devices that and Virtual Machine (2) were never designed with provide J2ME implementations generally execute a software JVM with no Java-specific hardware support. * This work is funded by the Next Wave Technologies Program (UK Government DTI) in conjunction with Sun Microsystems. The JavaMen research project is being carried out at the 1 The J2ME combines a set of configurations, profiles and optional packages University of York to capture the requirements of a that can be combined together to provide this environment. Broadly speaking, this gives a subset of the full Java standard edition with cut-down functionality virtual machine implementation with hardware support in the virtual machine and a smaller set of core and application libraries. that is compatible with a high-integrity subset of the processors that adopt this approach, each with slightly RTSJ, the Ravenscar Java profile (7). Briefly, the two difference optimisations. In essence however, the goals of the JavaMen project are to: architectures are similar; they mostly implement a stack • Design and implement a minimal real-time machine architecture with simpler bytecodes being Java virtual machine to run as an IP-core. executed in a small number of cycles and more complex • Provide distribution functionality through ones executed in microcode or software. PicoJava's which an application may perform a remote optimisations include features such as instruction invocation to offload part of its computation. folding and bytecode prediction, aJile provides simple This paper focuses on the first goal by identifying the synchronisation and scheduling primitives in microcode research niches that are being addressed. The aim here whereas JOP opts for as minimal a model as required to is to motivate the proposed solutions currently under provide predictable real-time guarantees. Other implementation. As will be shown in the next section, examples of existing Java Processors are Moon (14), some areas of this field have already been extensively Lightfoot (15), LavaCore (16) and FemtoJava (17), each researched. While adopting whenever possible positive providing different stack-based implementations. results from existing research in our own LavaCore and FemtoJava allow an analysis of the implementation, this work is unique in that it optimises application to be carried out in order to fine-tune the for the real-time characteristics of the application while hardware generated, thereby providing an application- supporting a flexible co-design strategy for application- specific hardware solution. specific environments. In order to provide the best possible hardware support, The rest of this paper is set out as follows: Section 2 the JVM abstraction must be analysed in order to gives a brief overview of the state-of-the-art in Java identify the optimisations over a naive stack-machine processor research. Section 3 identifies the research implementation. In general this investigation is carried niches that are being addressed in the JavaMen project. out on a set of applications such as the SPECjvm98 (18) A brief description of the RTSJ and the basic principles benchmark suite with optimisations then being driven of hardware/software co-design is provided here in by the ``average'' application. The literature contains order to set the context of this work. Section 4 several examples of research into the characterisation of introduces the proposed solutions and, finally, Section 5 the Java runtime but with the goal generally being to concludes. drive the design of software JVMs. In (19,20), the authors use trace information to optimise components of 2. HARDWARE SUPPORT FOR REAL-TIME the runtime such as the method cache and the decision JAVA strategy of the JIT compiler. Other work applicable to software JVMs can also be used in hardware In 1996, Romer et. al. argued that there existed so much implementations. Examples include the optimisation of possible optimisation of standard Java runtimes that JVM operations such as synchronisation (21) and using proposing hardware support was premature (8). This is common application characteristics such as the average contentious statement given that software runtimes are size of objects in making caching decisions. emulations of the Java abstract machine and that proposed optimisations are only targeted at better El-Kharashi et. al. carry out a two-part investigation emulation. However, given the poor optimisation of into the architectural requirements of a Java software virtual machines at the time, this statement was microprocessors (22, 23). The goal of the work is to probably true. A number of early hardware direct the instruction set design of a hardware JVM by implementations of the Java virtual machine were discovering the common cases of bytecode execution. developed soon after this time but none reached any Their approach is to to insert probes into the main significant levels of distribution. As optimisation of interpretation loop of a software JVM in order to software implementations reaches its peak, hardware calculate information such as the frequency of execution support is once again beginning to prove necessary in and time cost of each bytecode when executing a given order to overcome the performance barrier of Java test-bench application. Other information collected interpretation (and just-in-time runtime compilation)