p, such minimalist client machines require less RAM and can even forgo a hard drive.
How does the NC accomplish this? It's dynamically linked to powerful Internet or intranet servers. Only a small percentage of the system services reside on the NC at any given time; the remaining services are stored on the server and loaded on demand. Put another way, the servers store most of the nonessential system services, and the NC dips into them only when JavaOS says so. The result is a thin client with fat services available.
A Portable OS
JavaSoft designed JavaOS around the Java Virtual Machine (JVM). The JVM is the central component of the platform-independent run-time module. Additional system services (written in Java) are layered on top of the JVM, as well as various APIs derived from the Java Development Kit (JDK). These services and APIs have the traditional advantages of the Java language: dynamic class loading, run-time bindi
ng, platform independence, and security.
JavaOS is well suited for companies that want to standardize on a full-scale solution, because you can run Java applications -- without porting -- on every Java-enabled platform. With JavaOS powering both the boss's JavaStation and a field-service representative's remote paging device, information flows in a uniform and consistent format throughout the enterprise.
Because it's portable, you can install JavaOS in any number of embedded devices. It operates with native kernels such as Mach and Solaris's Green Threads (a cooperative multitasking kernel that early JavaStations use), and with a variety of real-time OS (RTOS) kernels.
JavaSoft achieved JavaOS's portability by writing a great deal of it in the Java language. In fact, JavaOS 1.0 consists of 68 percent pure Java (a percentage that will grow in the future as the company adds more JDK support), 30 percent native C code, and 2 percent assembly language.
JavaOS has already been ported to num
erous processors. These include the StrongARM, the PowerPC, the SPARC family of processors, the Hitachi SH-3, and the x86 product line from the 486 on up. The JavaOS license includes permission to modify system services, as long as you maintain compatibility with JDK standards.
JavaOS Architecture
JavaOS runs in a single address space, regardless of the platform it operates on. There is no supervisor mode, although it supports trusted code for device drivers. Trusted code lets drivers access classes not available to normal Java applications. A collection of classes called the Java Driver Interface (JDI) provides support for device drivers.
The heart of JavaOS remains the JVM. Java system services, drivers, applets, and applications execute on the JVM. A microkernel provides basic platform services, as shown in the figure
"JavaOS Architecture."
There is also a bootstrap loader (which is called the
booter
) that loads the core OS image. JavaSoft wrote the JavaOS m
icrokernel mostly in C. It also uses small assembly language routines in areas where optimum performance is required.
The microkernel performs two main functions. First, it's tailored to a specific hardware platform so that it delivers optimum JVM performance. Second, the microkernel implements platform-specific functions such as multithreading, multiprocessing, memory management, interrupt handling, and native acceleration for critical system operations (e.g., video output).
Because it adheres to the thin-client model, the JavaOS native kernel weighs in at around 90 KB. The JVM and C support classes increase this footprint by 250 KB. Support for JDK 1.0 classes adds 1 MB of Java code, and JDK 1.1 support adds 1.5 MB to that. Thus, for 2 MB you get an embedded OS, while 8 MB (16 MB is recommended) gives you a network-capable OS with a browser.
JavaOS Boot System
The JavaOS boot system consists of 128 KB of code (this varies with the implementation), whose duty is to first load the c
ore OS image and inform it of the device configuration of the platform. The output of the boot interface is a standard IEEE-1275 Open Firmware device tree, which defines the platform's devices and their interconnections.
For simple devices such as pagers, this information may consist of a precompiled data structure. For NCs with expansion slots, this boot configuration is determined using an OpenBoot PROM. JavaOS is bootable from ROM, flash memory, a hard drive, a floppy disk, or the network. Booting JavaOS from the network ensures that the most current core OS image is loaded to the client, but it increases network traffic.
Device Drivers
JavaOS drivers access devices indirectly through platform classes that abstract interrupts, addressing, and memory management from the device hardware. Because drivers are shielded from direct contact with the hardware, OS integrity is maintained and processing errors are minimized.
Although independent of the system memory model, addressing schem
e, and interrupt architecture, device drivers are nonetheless tied to a specific device/bus combination. In this sense, drivers still reflect the idiosyncrasies of particular devices and the bus architectures for which they are designed.
Drivers are associated with devices by way of a ROM file system linked into the OS binary. A special driver directory contains entries for device drivers appropriate for the platform.
Some of these drivers are linked in; in other words, their code is part of the basic OS image. The JavaOS network driver, for example, is always linked in, because it must be present at boot time to obtain other system services from the network. Other drivers exist outside the core OS image; the code for these drivers may be resident on the network.
Because JavaOS is network-centric, you use HTML files to identify drivers in the ROM file system. One entry in a driver HTML file is a URL defining the location of the driver code. This URL can point to a location in the OS binary (
as in the case of the linked-in network driver), or it can point to a location on the network.
A special system class known as the device manager reads device information from the device tree and builds the system device database. This database includes entries for each device on the platform. It keeps track of which class files implement interfaces to the different devices. The device manager uses the ROM file system to associate interfaces and devices with device drivers, as shown in the figure
"Booting JavaOS."
Because device drivers in JavaOS are identified using HTML files, it is possible to use a Web browser to view the system-device topology even on another JavaOS client (permissions allowing). This is useful for remote diagnosis and debugging.
It is also possible for the system device database to update itself dynamically as devices are added or removed from the system. This is true whether access occurs by way of hot-pluggable cards or by network installation.
One Hot Brew
JavaOS provides fat-client functionality with a thin-client footprint. Eventually, JavaOS can be counted on to let large enterprises standardize on a scalable Java delivery solution for pagers, digital phones, NCs, and workstations.
JavaOS provides an opportunity for kernel vendors to expand into the larger market for Java-application platforms. By embedding its kernel beneath JavaOS, a kernel vendor maintains the technological advantages of its product while gaining competitive access to a large installed base of Java applications.
Large-scale deployment of JavaOS may lead to increased network traffic and greater vulnerability to server downtime. But future versions are expected to implement object caching, possibly based on a least-recently-used algorithm. Object caching will substantially lessen network traffic and decrease vulnerability to server downtime. Caching may require the presence of flash memory or a small hard drive on the client platform.
illustration_link (27 Kbytes)
Two-thirds of JavaOS is written in Java, while the microkernel is written in C.
illustration_link (18 Kbytes)
JavaOS uses an Open Firmware device tree supplied by the boot code to locate the platform's device drivers.
Charles M
irho is an author/programmer working in Silicon Valley. You can reach him at
mirho@pacbell.net
. Tom Clements is a technical writer for Sun Microsystems' JavaSoft division. You can reach him at
tom.clements@eng.sun.com
.
JavaOS: Thin Client, Fat Service
