August 1, 1997

Java perks up embedded systems

Richard A Quinnell, Technical Editor

Java is expanding beyond the Web into embedded systems. Although some problems with the pairing, including a shortage of tools beyond initial debugging, are slowing the expansion, the eventual payoffs will be worth the wait.

Since its introduction in 1995, Java has received unprecedented, perhaps excessive, attention. Yet, beneath all the hype, Java has valuable attributes that can benefit embedded-system design. Adequate tools are only just emerging, however, and tool sets remain incomplete.

Java has received so much attention because of its link to the increasingly popular Internet. Java promises both hardware and operating-system independence; its philosophy of "write once, run anywhere" is a perfect match for the Internet's wildly heterogeneous environment. As a result, the Internet community has embraced Java with abandon.

Java delivers on its promise of independence by breaking code generation into a compile-time environment and a runtime environment (Figure 1). Compilers for Java typically don't produce machine code. Instead, they produce an intermediate result, called "byte code." The machine executing the Java application runs a Java virtual machine (JVM), which interprets the byte code into machine-specific language. In theory, any machine running a JVM could execute any Java byte code.

This JVM-based runtime environment has several features that enhance its appeal for Internet use. For instance, the JVM provides extensive code validation. Before executing the byte code, the JVM makes sure that the code won't attempt to alter the machine's basic behavior. Such checks help prevent faulty code and viruses from affecting the system.

Java's runtime environment also makes heavy use of class libraries. These libraries are predefined functional blocks that are part of the Java execution environment. Programmers can incorporate elements of the libraries into their code but need not provide these elements when distributing the code across the network. The libraries already reside on the target machine.

Java's widely touted portability advantages stem from these features of Java's runtime environment. But Java has value even without such an execution environment. It is a useful programming language in its own right.

Java avoids C++ dangers

The Java language is an object-oriented relative of C, similar to C++. Java adds features such as making all primitive data types a fixed size, building in support for string manipulation and multithread operation, and adding automatic bounds checking to array reads and writes. Java also simplifies programming by including standard class libraries that developers can depend on in all operating environments.

One significant difference between Java and C++, however, is that Java is missing many of C++'s dangerous and confusing attributes. One such attribute is multiple inheritance. A newly defined class in C++ can inherit attributes from several parent classes with the compiler making the final decision of what to inherit. Java allows only single inheritance.

Another missing attribute is the overloaded operator. Developers working in C++ can extend the definition of operators to handle additional data types. The operator for multiplication, for example, can have separate definitions for real and complex numbers. Java prohibits such ambiguity.

One of the most significant absences in Java is that of memory pointers and pointer arithmetic. This absence prevents problems, such as memory leaks, from ever arising, and it also simplifies programming. The developer does not have to keep track of memory allocation and deallocation. Instead, the underlying operating system performs background "garbage collection," automatically freeing unused memory blocks and defragmenting the memory space.

Embedded-Java problems

Unfortunately, this absence of pointers creates one of the most significant problems that Java faces in embedded systems: Direct access to hardware is difficult or even impossible. To ease that problem, the Java runtime environment allows Java programs to access machine-language or C and C++ routines using what Sun calls "native methods." Unfortunately, use of native methods compromises Java's portability because native methods are platform-specific.

The absence of pointers also indirectly compromises Java's real-time performance. Java's garbage-collection algorithm, which stems from the lack of pointers, runs to completion once activated; you cannot halt the algorithm partway through. Because the amount of memory that needs collection is a random value, the algorithm's execution time is also random. This lack of predictable timing is deadly to real-time operation.

The interpreted nature of Java byte code also slows execution. An interpreted Java program typically runs at 5 to 10% the execution speed of a comparable compiled C++ program. To get around this problem, vendors are bypassing the JVM with just-in-time (JIT) compilers. The JIT compilers convert Java byte code into machine code just before execution. The resulting machine code runs at speeds comparable to compiled C++, but overall program execution is slower because of the compilation time.

JIT compilers are also RAM-intensive, which is a drawback in embedded systems that have limited memory resources. The compiler must keep symbol tables in memory during compilation and execution. It also keeps the compiled code in memory to boost system performance by not recompiling code that the application reuses. JIT compilers can wind up requiring RAM as large as 10 times the size of the application program's byte code.

The interpretive JVM is no slouch when it comes to consuming memory, either. Sun estimates that a full implementation of its JavaOS with JVM and class libraries requires 4 Mbytes of ROM and 2.5 Mbytes of RAM for the program and its dynamic storage requirements. A minimal version would require 512 kbytes of ROM and 128 kbytes of RAM. Application-software needs add to these figures.

So, why embedded Java?

With all these apparent problems, then, why would any embedded-system designer even consider Java? To answer this question, you must look carefully at the applications using Java and what tool vendors are doing to address Java's problems.

A variety of applications call for, or can benefit from, Java. Consider, for example, Internet appliances. These devices must be able to handle Java byte code because of their connection to the Internet. Inevitably, that connection leads the appliance to a Web site that sends out Java code. Such appliances, therefore, must provide the memory needed for the JVM. On the other hand, these appliances are not especially concerned with real-time performance or even rapid execution. The performance problems of Java are not a factor.

Another class of applications that can use Java is network-connected devices. A growing number of network-connected devices use Internet technology for the user interface and for device control (Reference 1). In such networks, the individual devices may not need to run Java applications but may source Java code to communicate with the user or the network server. Such configurations keep the Java runtime environment confined to the large user and server machines, allowing the network-connected devices to stay small and run fast. Real-time performance may be an issue in the Java-enabled system servers, however.

Java is also valuable in systems that need to be reconfigurable. Such systems are not necessarily network-connected but use the Internet's download-and-execute model of Java to reconfigure system operation. Java's advantage in such applications is that Java byte code is more compact than corresponding machine code, reducing download time. It is even possible, if the application program is large, that the byte code's compactness can more than compensate for the size of the JVM, so you need less overall program memory.

An advantage that Java brings to all systems, reconfigurable or not, is that Java programming can make good use of existing code, simplifying the maintaining and upgrading of system software. You need not compile existing code to blend it with new code. The byte code produced by any Java compiler will mesh with byte code from any other compiler.

The potential uses of Java in embedded systems have stirred up a flurry of development-tool introductions, and more tools continue to appear (Table 1). The pace of such tool development is tremendous, fueled in part by a $100 million Java-development venture-capital program sponsored by Sun, IBM, and others. Some computer-system vendors estimate that 80% of the new start-up companies in Silicon Valley are related to Java development.

Tool must match application

Your choice of a Java development tool depends mainly on your application. For the most part, tools fall into three categories: rapid-applications-development (RAD) tools, programming environments (PEs), and integrated development environments (IDEs). A smattering of other tool types also exists.

RAD tools primarily support developers targeting desktop computers. Such tools often allow graphical drag-and-drop programming using existing Java components and incorporate a Java-enabled Web browser for testing the results. They allow designers to use a huge body of Java-applet libraries available from a variety of companies. Symantec's Visual Café is a popular example of a RAD tool.

These RAD tools are suitable for developing Java code for network-connected devices that source Java code to a user or server. The tools allow quick and, sometimes, coding-free creation of Java applets that execute on a remote machine. Typically, however, RAD tools don't readily handle large applications.

For large projects, you need to turn to a PE or an IDE. PEs provide tools for code entry, editing, and debugging, but they rely on a third-party Java compiler, typically SunSoft's Java development kit (JDK). IDEs, on the other hand, are complete development tool suites, including compiling, debugging, and project-management tools.

Both PEs and IDEs develop Java applications that will run on a full implementation of the Java runtime environment. They are both suitable for network-connected devices and embedded systems large enough to implement the JVM or a JIT compiler. The underlying operating system of such large embedded systems can be SunSoft's JavaOS (if no real-time constraints exist) or a real-time operating system (RTOS) running a JVM.

RTOS makes Java real-time

The RTOS-with-JVM approach addresses the real-time concerns about Java in embedded systems, and most major RTOS vendors have incorporated a JVM into their operating systems. For the most part, RTOS vendors map the JVM to a process or thread within the operating system and give Java a private memory space. These actions isolate the JVM's behavior from that of the rest of the system. The operating system can halt the isolated JVM without disrupting garbage collection, allowing time-critical code to execute.

The PERC (portable executive for reliable control) virtual machine for Java, developed by NewMonics and used in ISI's pSOS, takes a different approach. PERC offers a garbage-collection algorithm that is incremental and pre-emptable. Instead of needing to isolate Java to its own thread and memory space, ISI can integrate Java's memory use with the rest of pSOS.

PERC also extends Java to add real-time constraints with the "Atomic" and "Timed" statements. PERC defines Atomic statements as code segments that must run in their entirety or not at all. Timed statements have a maximum amount of time in which to execute. These two statement types let designers control when and how critical sections of code execute in the runtime environment.

Whether you use PERC, a JIT compiler, or Sun's JVM, the incorporation of Java into an RTOS has the potential to bring the RTOS' full suite of tools to bear on Java code. How well that potential is realized varies with vendor, however. For many vendors, the RTOS tools can help debug the interaction be-tween the JVM and the rest of your application, but the tools don't debug the Java code. Developers must debug their Java code on a Java-specific IDE or PE and then treat that code as working and debug the rest of the application with the RTOS tools.

Wind River's Tornado for embedded Internet is an exception to this separation. Tornado can instrument the Java byte code that it runs as threads under VxWorks. This instrumentation gives Tornado's tools access to your Java code's behavior. The WindView system-visualization tool, for example, can locate Java performance bottlenecks.

Tool sets missing parts

Bringing RTOS tools to bear on Java code, as well as the advent of Java-specific development tools, is only the first step toward realizing Java's full potential for embedded systems. Tool sets for Java are by no means complete. Designers of embedded systems are accustomed to having a variety of tools to handle every stage of development. Such tools include source-aware debuggers to track bugs to their origin, timing- and performance-analysis tools to help optimize code, in-circuit emulators and logic analyzers to examine hardware/software interaction, and test tools to validate code and ensure reliability.

The debuggers that come with Java IDEs tackle the first of these tool needs. They can help identify code errors and track them back to source code. As for performance analysis, Wind River's Tornado is a start. For the rest of a designer's needs, tools are only now starting to emerge.

For performance analysis and code optimization, Intel recently an-nounced version 2.5 of its VTune analysis tool with Java capability. VTune works closely with the Pentium architecture to statistically sample processor state and build a profile of code execution. It then offers designers suggestions on how to modify code to improve performance.

On the test side, Software Research offers TCAT (test-coverage-analysis tool) for Java. TCAT monitors code execution during your validation testing. It then offers graphic, text, and tabular reports on which sections of code you have tested. Such reports help designers ensure testing has been thorough in uncovering bugs.

For code maintenance, Automated Testing Solutions offers version 3.0 of its X-Tester regression-testing tool. Regression testing automates the retesting of code following upgrades and bug fixes. This retesting helps ensure that no new bugs creep into code during modifications.

Such test and analysis tools help round out the Java developer's tool kit, but there's a long way to go. Part of the reason Java faces such tool limitations is that its current implementation is as an interpreted language. It is difficult to separate the execution of user code from the underlying execution of the virtual machine. Thus, timing-analysis tools, in-circuit emulators, and the like are hard for vendors to implement.

For embedded-system designers, however, Java need not re-main an interpreted language. In many classes of applications, such as those with a unique hardware configuration, the portability that the JVM provides to Java code is not a significant factor. For such applications, designers can use Java simply for its high-level-language benefits and to leverage the growing array of Java applets emerging from the desktop-software market. All that designers need to do is bypass the virtual machine and compile Java code all the way down to machine code. Alternatively, they can run their Java byte code on a processor for which the byte code is the machine language.

Both alternatives will soon be available to embedded-system designers. Both the Asymetrix SuperCede and the Visix Vibe IDEs can already compile Java code to machine language. This ability, in turn, allows the debugging tools to focus solely on the application code without the filter of the virtual machine.

Java-byte-code processors are not far behind. Sun has announced development of the JavaChip processor family for direct execution of byte code. In addition, Sun is working with other vendors to develop specialized versions of its picoJava core. Toshiba (Irvine, CA) will develop a low-power version of the processor. Rockwell Collins (Cedar Rapids, IA) will develop a low-power, low-cost version for low-end consumer products, such as cellular phones. LG Semicon (Seoul, South Korea) is developing a Java processor for information appliances, such as Internet TVs. All will be able to execute Java byte code as their native code, and several are slated for introduction in 1997.

For embedded-system developers, then, Java is becoming a viable alternative to C and C++ as a software-development language. Although Java has some significant drawbacks in embedded use, workarounds exist. The code size of a Java implementation may not be a factor in some applications. Several approaches address the real-time performance of Java. JIT compilers and native-Java processors help address execution-speed concerns. Also, tool suites are beginning to flesh out as more vendors release Java-compatible tools.

An industry effort is also under way to change Java for embedded users. One recent initiative is Sun's an-nounced development of an embedded-Java specification, due out for public comment by the fourth quarter of this year. This embedded-Java spec will be a subset of the full Java implementation, scaled to meet the needs and limitations of embedded-system design.

Approach with caution

Still, embedded-system developers need to approach Java with some caution. The language is relatively young and still in transition. Sun's JDK 1.1 implementation, for example, made changes over version 1.02 in its handling of native methods. The new JDK also expands the basic classes that are part of the Java environment. Thus, tools developed for version 1.02 won't properly handle native methods or access the new class features. Further, many tools are in only their first or second generation. User reviews posted on the Internet report errors and problems in many of those tools.

Tool vendors are solving such problems, however. In addition to new tools, updated versions of existing tools have been or will soon be released that address the concerns expressed by the early reviews and that incorporate the features of JDK 1.1. And Java's still-fluid definition is solidifying. Sun has taken the first steps to cast Java as an international standard by applying to the ISO/IEC JTC1 (Joint Technical Committee 1). If approved, the Java specification could be an international standard within a year.

The best approach for embedded-system developers, then, is one of cautious adoption. If the application can tolerate Java's constraints, the tools exist to proceed with development. Their relative immaturity means that development will be somewhat slower and more frustrating than it would be with more mature languages. But the potential payoff is more reliable software in a language that will become, over time, an easier and faster avenue to software development than C and C++.

Reference

1. Quinnell, Richard A, "Web servers in embedded systems enhance user interaction," EDN, April 10, 1997, pg 61.

| EDN Access | Feedback | Table of Contents |