JavaOS: An Operating System for Small Devices

Designed for PDAs and embedded systems

Steve Mann

Steve is publisher and editor of PDA Developers, a bimonthly magazine for developers creating products for hand-held devices, and The Hand-Held System Integrator Directory. He also produces the semi-annual PDA Developers conferences. He can be reached at [email protected].

Java has come a long way since its introduction last year as a net-capable programming language. To cope with all the market and product activity, Sun Microsystems spun off a subsidiary, JavaSoft, to focus on the myriad applications of Java. At Sun's JavaOne conference, the company showcased Java as a solution for everything you might want to do on the Internet or with an intranet--client/server computing, object-management systems a la OpenDoc or ActiveX, web servers, and of course, the ever-popular web-content creation.

Surprisingly, Sun didn't stick to its traditional large, distributed-system arena. It also announced JavaOS, a complete operating system with a minimalist set of application and network services and a PDA-size memory footprint. You can even strip out part of the traditional operating-system services (window management, for instance) and fit JavaOS into a memory space appropriate for an embedded processor. Available by the end of 1996, JavaOS may do the same thing to the PDA and embedded markets that Java has done to the Internet--wreak havoc.

A Traditional Java Implementation

You can implement Java in virtually any type of computer architecture, whether an operating system or a mere application, by porting the Java Virtual Machine and the Java foundation classes to the architecture. The run-time environment doesn't matter as long as the Java API remains intact so that Java applets can run.

Figure 1 shows a Java implementation as part of a conventional operating system. The topmost layer, the Java Foundation, Abstract Window Toolkit (AWT), and Network and I/O classes are all written in Java. The run time, including the interpreter and garbage collector, is written primarily in platform-independent C. There is some platform-specific code in both C and assembler, but it's minimal. There are also libraries like libawt and libnet that map the platform-independent classes to OS-specific APIs. All of this sits on top of the native operating system.

Java requires several types of operating-system support:

• Context Switching. The host system must provide some type of context-switching mechanism. If it also provides support for threads, Java can take advantage of that to optimize its own multithreading.
• Memory Allocation. The run time manages its own heap and garbage collection, but it still needs a low-level memory-allocation mechanism.
• GUI Toolkit. Java has platform-independent windowing and graphics tool kits, but it relies on the host system to provide a set of graphics primitives to implement those tool kits.
• Networking. The host system needs to provide a suite of standard networking protocols. Java provides the abstraction to use those protocols.
• I/O. Java has standard classes for streams and files. In addition, Java applets assume that a device has some standard I/O devices like a keyboard, mouse, and display. The platform needs to provide basic I/O services to support these classes.

JavaOS: No Host Required

When Sun created JavaOS, it essentially had to remove as many of the platform dependencies as possible and migrate them to platform-independent code. First, Sun implemented the smallest possible set of kernel services needed to support the virtual machine. The company then used the virtual machine and the new minimalist kernel to implement all the other services--GUI support, networking, I/O drivers, and a file system. Finally, Sun checked its work to make sure it supported the full Java API. Applications written for JavaOS should run on any Java-enabled platform. Figure 2 shows the JavaOS architecture.

The JavaOS kernel is not a general-purpose kernel. It's designed specifically to support JavaOS. The kernel provides three basic types of services:

• Booting. The boot-strap code allocates memory for the Java heap, DMA regions, and I/O device registers. It also detects hardware devices and maps them to the appropriate device drivers.
• Traps and Interrupts. This code provides traditional I/O services, interacting with hardware devices and passing information to and from device drivers.
• Thread Support. This code supports context switching for the virtual machine. The Java Virtual Machine uses threads quite a bit. A typical system has dozens of threads running at any one time.

This minimalist kernel has several advantages over a more traditional, general-purpose operating system. First, its memory footprint is modest (more about that shortly) because it only provides a small set of critical functions. Second, because of the memory protection provided by the Java programming language, all applications can run in a single address space. This minimizes context-switching overhead. It also means that the entire system can run in supervisor mode. Again, this minimizes operating-system overhead, simplifies programming, and makes the system faster.

JavaOS doesn't require a memory-management unit (MMU). If one is present, the operating system can use it to make several disjoint address spaces appear contiguous. After the system boots up and the MMU is initialized, it's not used again.

Higher-Level Components

The Java Virtual Machine does more than just interpret bytecodes. It is also responsible for memory management, exception handling, and thread coordination. The JavaOS virtual machine is almost identical to the one provided with the Java Developers Kit 1.0. The memory-management and garbage-collection algorithms have been slightly modified.

The device drivers are written entirely in Java (JavaSoft is in the process of defining a Java Device Driver interface for third-party developers). Sun was able to do this by abstracting two operations into small C support classes: a MemoryObject class that gives drivers access to specific memory locations, and an interrupt-dispatch class. The methods of these classes are not made available to Java applications. JavaSoft claims to have more than a dozen drivers currently finished.

Like the device drivers, the network protocols are also written in Java. The current suite includes TCP, UDP, IP, and ICMP. JavaOS also uses DNS and NIS for host-name lookup and login services, plus DHCP for dynamic IP address allocation, minimizing network-administration requirements for connectable devices. There is a Network File System (NFS) client and support for Simple Network Management Protocol (SNMP) so that JavaOS devices can be managed in a network environment.

JavaSoft rewrote much of the windowing system, making it more appropriate for the JavaOS environment. Although it is a full implement of the Java Abstract Window Toolkit (AWT), the windowing system is designed to take advantage of its a priori knowledge of the lower levels of the operating system. The lowest levels of the graphics libraries are written as native methods because they need direct access to frame buffer memory locations. The rest of the AWT is written in Java.

Performance

JavaSoft has (so far) done little JavaOS performance optimization, and native methods are not extensively used. Also, the current implementation doesn't use a just-in-time compiler to improve performance. Nonetheless, JavaSoft is very pleased with the preliminary performance of the operating system.

TCP/IP throughput, about 500 Kbits/sec, is twice the original goal, and more than suitable for web browsing. Also, JavaSoft is pleased with the benchmarking they have done to date. JavaSoft attributes the good performance to the elimination of several layers of operating-system overhead that more traditional, general-purpose platforms require.

On the high end, a complete JavaOS system, including the HotJava browser, can fit into 4 MB of ROM and 4 MB of RAM. The ROM includes:

• JavaOS, including the kernel, drivers, virtual machine, and standard classes.
• The windows, graphics, and networking components.
• HotJava.
• About 1 MB for various fonts and styles.

If the ROM code is XIP (execute-in-place), which JavaSoft claims is possible, the dynamic RAM requirements are about 2.5 MB for JavaOS and HotJava, leaving 1.5 MB for downloaded HTML pages, applets, and images. If you create a system that doesn't need windowing or HotJava, the memory requirements are reduced by approximately half.

Although JavaSoft presents JavaOS as ideal for Internet Appliances, the company also likes to fit it into the low-end embedded system market. In its smallest configuration, with no graphics code, no network support, no font support, and no browser, JavaOS can fit into about 128 KB of RAM and 512 KB of ROM. You also need additional RAM for applications and run-time requirements.

Current Status

JavaSoft has promised delivery to qualified licensing partners by Q4, 1996. The company plans to unveil real products as early as January 1997. While that might seem a bit quick, some Sun partners have probably already been working with JavaOS for several months. JavaOS currently runs on two chip sets--SPARC microprocessors, and Intel x86-compatible processors. JavaSoft has stated that the platform is being ported to other instruction sets.

One logical JavaOS processor is the Mitsubishi M32R/D, a 32-bit RISC CPU with 2 MB of on-board DRAM, a 2-KB SRAM cache, on-chip DSP capabilities (including the appropriate hardware arithmetic support), plus memory controller and peripheral circuits. Clocked at 66 MHz, the M32R/D is rated at 52.4 Dhrystone 2.1 MIPS.

Mitsubishi has been partnering with Sun for several years. In May, Mitsubishi announced that it had ported Java to this chip, running on top of an unspecified microkernel. Because of the JavaOS architecture, once Java is ported, it shouldn't be too tough to port the complete operating system.

Another logical chip for JavaOS is Sun's own JavaChip. Announced in February, JavaChips come in three flavors: small, medium, and large. Each contains a silicon-based Java interpreter that can run Java code right from startup. The three chips differ primarily in clock speed and additional on-board silicon. The low-end picoJava should be sampling by Q4, 1996.

Although architectural details have been sketchy, these chips should have the appropriate hooks to run a system like JavaOS, or perhaps Sun will create yet another JavaChip specifically for JavaOS.

The Grand Scheme of Things

At first glance, JavaOS on a hand-held device appears to be the quintessential Network Computer, optimized for web browsing, rich content, and industry-standard connectivity. JavaSoft is so busy focusing on its basic technologies, however, that it hasn't started thinking about other aspects of the hand-held market--applications software designed specifically for mobile computing, desktop connectivity, and the like.

Manufacturers may find that, instead of hot web browsing, consumers prefer a Newton, with a good set of PIM applications, running Apple's Internet Enabler stack and AllPen's NetHopper (limited to text-only Web browsing). Or Microsoft's long-rumored Pegasus operating system with a built-in HTML browser, PIM software, and tight Windows desktop integration may be more compelling.

However the market shakes out over the next few years, it's clear that JavaSoft will alter the hand-held device landscape if the company continues its efforts. At the very least, JavaSoft has tossed its hat into a part of the computer arena that is still viewed with skepticism by some platform creators. Once manufacturers release JavaOS-based devices, we'll find out if consumers care.

Figure 1: A Java implementation as part of a conventional operating system.

Figure 2: The JavaOS architecture.