By: Hank Shiffman, JEDI Technologies Inc.

Contents
Java as an application platform
Java: the downside
The Java coprocessor: easy augmentation
In silicon: small footprint, overhead
Wireless Java in a nutshell

According to market predictions provided by cell phone maker Nokia, by the year 2004 there will be 600 million users of Internet-connected cell phones worldwide. This number is significant for two reasons. First, it represents a leap from near zero in 1999 to half the 1.2 billion phones in use in less than five years. Second, at about that same moment, there will be more cell phones on the net than PCs.

Widespread implementation of handheld Internet applications will require the creation of an adequate platform. For the handheld Internet to succeed it needs software. And getting a large volume of software requires a standard platform, one that lets developers build their applications without having to create a special version for each manufacturer‰s device. The lesson of compatible and almost compatible PCs is clear: any amount of extra effort required to support a nonstandard product is too much.

Getting to a PC standard required computer makers to accept major compromises and to ‹innovate at the edges,Š leaving the major decisions to Intel, Microsoft, and a few others. The challenge for handheld makers will be to achieve a standard without compromising on essential features. When designing a device requires trading off size and weight, power consumption, performance, cost and user features, it is unlikely that a single standard hardware platform could serve every requirement. However, a single software platform does exists in Java.

Java has other benefits for wireless platforms, such as compactness and verifiability. Compactness refers to the fact that Java byte code for a given application takes up less room than the native code of most any processor. Java instructions are both high level (often implementing complex concepts as a single operation) and have varying lengths. This combination permits typical applications to require just 1/8 the memory needed by typical RISC microprocessors. Compact code has two benefits in wireless devices: first, it allows larger and more complex applications to fit into the device‰s limited storage; second, it dramatically reduces the time required to transfer those applications into the device from the network.

Verifiability refers to the ability of a Java VM to determine whether a piece of code violates the rules of acceptable practice and, if necessary, to reject it as posing a security risk. It is easy to restrict a Java application‰s ability to do damage. In fact, Java‰s security mechanisms make it possible to define as many levels of security as we might want and to know that a program can‰t do anything more than we have permitted. For example, if a program requests Game Privilege, for example, we can know that it will never try to read or write any data beyond the single file containing the game‰s high scores.

Although native code compilers, JIT compilers and dynamic derivatives like Sun‰s HotSpot technology have made Java more performance competitive with native applications in desktop and server environments, their high memory requirements make them far less acceptable for wireless devices. If getting the best performance requires giving up that 8:1 code size reduction, Java suddenly looks a whole lot less attractive.

If fixing Java‰s performance in software is not practical for embedded applications, the alternative is to fix it in hardware. This was the idea behind the Java chip, a new kind of processor that uses Java byte code as its native instruction set. Java chips would run Java efficiently, at least as well as JIT solutions, without requiring all the extra memory a JIT needs for the translated code. Sun Microsystems was the first to develop such a microprocessor core, which it called picoJava; others have followed with new processor designs or by retrofitting existing designs to run Java byte code.

At this point, Java chips appear to be an evolutionary dead end. None has achieved performance anywhere close to a comparable microprocessor armed with a JIT. Most have inferior native code performance, and native performance still matters. Aside from the desire to continue to use at least some native applications, software builders must face the fact that Java is an application language. It is not capable of handling the low level interfaces required of a systems programming language. Operating systems, network interfaces, device controls all still require native code.

Even if Java chips were capable of the highest performance for both Java and native applications, they would still represent a difficult choice for device makers. Any new microprocessor requires a tremendous investment. It means a change in equipment, in all of the software already in use, in the experience and expertise of the development team. Just arranging for the porting of existing software to a new chip requires an investment of millions of dollars and many years. These are the sorts of costs and risks that are unlikely to appeal to most designers.

There are two approaches in use today for Java coprocessors. One is similar to a Java chip; the coprocessor does all the work when running Java and the main processor handles all the native code. A second approach attempts to maximize the value of the main processor. It uses the Java coprocessor for the VM‰s main instruction processing loop, fetching Java byte code instructions, decoding them, translating them to native instructions and managing the Java program counter and the operand stack. All of the real computation for the application takes place inside the native CPU.

This is the approach taken by the JSTAR accelerator developed by JEDI Technologies Inc (Santa Clara, CA). JSTAR is an instruction path coprocessor that was designed to reside on the same chip as a native microprocessor. Situated between the native processor core and its memory system, it operates as a kind of switch between Java and native modes. When native code is being executed JSTAR is idle; instructions are fetched from cache or memory and processed as usual.

JSTAR becomes active whenever control switches from native code to Java byte code. In this mode JSTAR intercepts instruction requests from the native CPU. Instead of fetching native instructions, JSTAR uses its own Java program counter to fetch byte code instructions and convert them into native code for execution by the native core. JSTAR handles many of the housekeeping functions of Java, relieving the native CPU of the more time consuming aspects of byte code interpretation.

The current implementation of JSTAR requires 30,000 gates and 45,000 bits of memory to support a 32-bit single-issue microprocessor. This translates to one square millimeter of silicon using a .18µ process, making JSTAR-equipped chips practical for a wide variety of devices. Power requirements are also suitable for wireless devices. JSTAR requires roughly 18 milliwatts of power at 100 megahertz (1.5 V), which represents 15% over the requirements of the original chip. During native code execution JSTAR can be shut down completely, reducing its power requirements to leakage levels of a few microwatts.

With this small increase in power consumption comes significant performance benefits. JSTAR running on a MIPS R3000 class processor with Sun‰s PersonalJava 3.0 and Wind River‰s VxWorks RTOS shows a 7X acceleration on Pendragon Software‰s CaffeineMark 3.0 benchmark as compared to the same hardware/software combination running an unaided Java interpreter. Work is in progress to convert JSTAR to other microprocessor designs, as well as to adapt other Java virtual machines to it.