| J-Lite: Java for Embedded Systems |
The extraordinary growth of Internet and pervasiveness of Internet protocols makes it possible to consider a wide market of versatile Internet appliances, ranging from public utilities such as printers and telecommunication devices, to professional systems such as medical equipment and computer systems.
The development of the JavaTM bytecode as a universally portable execution format for software systems makes it attractive for Internet appliance manufacturers to base their system over a small footprint Java execution environment. The JLite project aims at developing a small footprint Java execution environment offering real time capabilities for Internet appliances.
Leveraging out of the work already done in our Operating System Program and our Java Program, J-Lite goal is to provide a thin client Java execution environment that runs on standard processor architectures with minimum footprint, yet it provides real time capabilities and quality of service. This is achieved by implementing a Java Virtual Machine specialized for embedded systems. The hardware we use for the project is off-the-shelf hardware, typically Intel 486, MIPS, PowerPC or StrongARM running as low as 2-4 Megabytes of memory (without user interface).
J-Lite runs Java applets in an execution environment that may not exhibit all of the features found on a UNIX or Windows platform, but it is compliant to the Java specifications and is planned to incorporate real time features and implementation of real time Internet protocols allowing for implementation of systems requiring quality of service such as Internet telephony and cable TV modems.
The J-Lite execution environment is targeted to be adequate for a wide range of Internet appliances including:
We assume that most Internet appliances will have their own specific user interfaces (possibly none), suited to the targeted market (a set top box will largely differ from a plant controller or a network management device). Hence, we do not currently plan to develop a user interface over the J-Lite environment. J-Lite could be used as the core system for a network computer or a Personal Digital Assitant, but this would require adding the user interface matching the specific UI requirements of the targeted market.
We developed J-Lite by enhancing and adapting the Java runtime initially developed by Sun Javasoft to make it run over real-time micro-kernel technology.
We have phased our efforts to match our resource constraints and to address the priorities of our investors. The very high priority we have been adressing in the first release of J-Lite, now available, is the overall footprint of the system, providing adequate memory management and reasonable performance.
The Java runtime is integrated with the minimum set of services needed to run the Java execution environment and take advantage of the underneath real time features. For example, the Java threads are mapped directly to micro kernel threads Java applets.
As we want to ensure of good portability and industrial strength of our software, we are developing two ports of J-Lite simultaneously: one over a commercial micro-kernel and one over our own MK micro-kernel. The commercial micro-kernel we use is the VxWorks system from Wind River Systems.
Our micro-kernel was developed in our Operating System Program. For J-Lite we used a particular real-time version developed for the US Navy projects, which includes real-time features such as kernel pre-emption, guaranteed maximum latency, multi-threading with guaranteed context switch latency, and nano-seconds timers.
In the first generation of embedded Java systems that is now being built, people are often simply adding Java capabilities to an existing system. It means that the new system is re-using well proven existing C code as Java native methods (e.g. signal filtering code, commands of electrical engines) with an object oriented encapsulation. Doing so, a critical issue is the sharing of memory between the Java runtime and other services running on the embedded system. For example it may be the case that at one point a signal filtering native method needs a lot of memory, at another moment it may be the Java runtime that needs all memory available to process the filtered signal.
What we have done is that we have enhanced the memory allocation schema such that the Java heap can share memory with native methods. That is, memory is not "reserved" neither for the Java heap nor the C heap. System memory can be allocated at one time to the Java application if it needs to, or to the native methods.
There are several things we have done to reduce footprint of the Java Virtual machine and optimize memory usage. First we have done some code clean-up and have eliminated the heavy UNIX'sms that were in the initial Solaris code.
Second, the Java byte code is denser than commercial processors code, whether CISC or RISC processors. Hence, one way of reducing the footprint is simply to rewrite native code in Java. Typically that reduces the code size by a factor of at least 40%. One such example consists in re-writing the network protocol framework entirely in Java. This allows both reduction in the code size and optimizes memory usage as the network packets buffers can be drawn from the Java heap and garbage collected.
Of course this has an impact on performance, as the native code becomes interpreted, it also becomes slower to execute. However there are cases where the performance penalty is not actually perceived. For example, for Internet appliances that are connected to the network through 56K modems, or ISDN lines at 64 or 128K bits/second, interpreted code in that case is still much faster than the bandwidth can accomodate.
We have identified other ways of reducing footprint that we are implementing in the next release.
We are also addressing performance issues by rewriting the byte code interpreter loop in assembly language for a set of platforms, with an expected performance gain of 100%.
The deliverables of the project consist of:
We do have a version of the Java VM derived from JDK 1.1.6 that can run embedded Java applications in less than 1.5 Megs of memory. This version is available on the VxWorks operating system and supports ROM'ized classes.
In this new Release we have further reduced the footprint from our previous 1.1.3 Rlease and we support ROM'ized classes. This version is expected to run a Java application in less than 1 Meg of memory. This version also supports the Turboj compiler.
We are working now on a new version of J-Lite based on JDK 1.1.6 where we are further reducing the footprint, support modem based devices, and support PC Card devices (in particular flash cards or network cards)
To continue our footprint reduction efforts, this version is expected to run a Java application in less than 768K of memory. We plan to support in next version ROM classes that belong to the address space (the ROM is mapped in the VxWork address space) so that the RAM memory size can possibly be reduced to 1 Meg. This version will also support the Turboj compiler.
After we have migrated to 1.2 Java and we have reached our objective of reducing the footprint to a minimum level, our next objective is to provide better performance, extend the profiling and measurements capabilities for developers and increase real-time capabilities of the system.
Developers of applications for J-Lite currently have a limited set of tools for measuring performance of their Java applications and analyzing performance bottlenecks. We aim at providing such performance analysis tools, possibly for end of 1998.
Another area of focus is real time capabilities. We want our users to be able to implement Internet appliances that will provide adequate, predictable response time, and quality of service.
Currently, the only real time feature that we support is guaranteeing that higher priority threads will execute before lower priority ones and we support priority inversion on locks.
In addition, the J-Lite environment will include real time Internet protocols that will make it possible to provide adequate guaranteed response time and quality of service. It will implement protocols such as RTP (Real Time Protocol) and RSVP (Reservation of Service Protocol) that make it possible to develop various applications ranging from real time process control to Internet telephony and continous media stream.
[an error occurred while processing this directive]