Also available in PDF.
The purpose of this paper is to describe the choices made by Sun's KVM technology team when designing the K virtual machine (KVM) for consumer and embedded devices.
The K virtual machine (KVM) is Sun's newest Java virtual machine technology and is designed for products with approximately 128K of available memory. The KVM fills a very important role in Sun's Java virtual machine product offerings, and will form a part of a completely new Java runtime environment. This environment is highly optimized for small-memory limited-resource connected devices such as cellular phones, pagers, PDAs, set-top boxes, and point-of-sale terminals.
The KVM has been developed as part of larger effort to provide a modular, scalable architecture for the development and deployment of portable, dynamically downloadable, and secure applications in consumer and embedded devices. This larger effort is called the Java 2 Platform Micro Edition (Java 2 ME). Connected, personalized, intelligent tools are becoming increasingly important in our business and private lives. Java 2 ME is an architecture designed to address the specific technical requirements of these new information appliances.
While connected consumer devices like pagers, cell phones and PDAs have many things in common, they are also diverse in features, form, and function. Information appliances tend to be special-purpose, limited-function devices, not general-purpose computing machines like servers and desktop systems. Serving this market calls for a large measure of flexibility in how Java technology is deployed. Flexibility in deployment is also important because over the lifetime of any one connected device, its applications and capabilities can change and grow to accommodate the needs of the user. Users want the ability to purchase economically priced products with basic functionality and then use them with ever-increasing sophistication. Java technology enables users, service providers, and device manufacturers to take advantage of a rich portfolio of application content that can be delivered to the user's device on demand, by wire or over airwaves.
The Java 2 ME architecture is modular and scalable so that it can support the kind of flexible deployment demanded by the consumer and embedded markets. For low-end, resource-limited products, Java 2 ME and the KVM support minimal configurations of the Java virtual machine and Java APIs that capture just the essential capabilities of each type of device. As device manufacturers develop new features in their devices or service providers develop new and exciting applications, these minimal configurations can be expanded with additional APIs or with a richer complement of Java virtual machine (Java VM) features. While the KVM is targeted at devices containing 16- or 32-bit processors and a total memory footprint of approximately 256K bytes, KVM can be deployed flexibly to address a range of trade-offs between space and functionality. In addition, Java 2 ME provides a range of virtual machine technologies, each optimized for the different processor types and memory footprints commonly found in the consumer and embedded marketplace.
The KVM is engineered and specified to support the standardized, incremental deployment of the Java virtual machine features and the Java APIs included in the Java 2 ME architecture. The Java 2 ME architecture defines a small core API which must be fully implemented in every Java 2 ME compatible device. Java 2 ME is deployed in several configurations. Each configuration addresses a particular "class" of device and specifies a set of APIs and Java virtual machine features that users and content providers can assume are present on those devices when shipped from the factory. Application developers and content providers must design their code to stay within the bounds of the Java virtual machine features and APIs specified by that configuration. In this way, interoperability can be guaranteed among the various applications and devices in a particular class.
The purpose of this paper is to describe the choices made by Sun's KVM technology team when designing the K virtual machine for consumer and embedded devices.
Chapter 2 of this white paper sets the stage for this discussion by providing an introduction to the Java 2 Micro Edition. Then Chapter 3 reviews the proposed features of the KVM and API, and discusses how the features of the VM are related to the definition of Java 2 ME configurations. Chapter 4 reviews the optimizations that went into designing the KVM as well as the Java 2 ME core API. Chapter 5 summarizes the considerations that went into the design of the KVM and API. Finally, Chapter 6 discusses the future direction of the KVM technology.
Java 2 Micro Edition
Sun, in conjunction with industry partners, will define and evolve the Java 2 Micro Edition and its configurations. This is done with the JCP (Java Community Process). The Java 2 Micro Edition includes two standard configurations, which are subsets of the Java 2 Standard Edition core APIs, and which will fit in 128k of ROM.
A profile is a collection of Java technology-based class libraries and APIs and a specific configuration that provides domain-specific capabilities for devices in a specific vertical market.
The following features defined in The Java Virtual Machine Specification are optional in the KVM architecture. In each case, a feature is designated "optional" because:
Features not explicitly identified in the following list are required and must be implemented in all configurations.
This is a very prelminary draft of the Java 2 ME APIs. We anticipate adding substantial additional functionality drawn from Java 2 Standard Edition core packages.
The following list contains only the class names. Many of these classes have been significantly subsetted in order to reduce the minimum required functionality to key fields and methods.
Object, Runtime, System
These classes are included in the core API because they are fundamental to the operation of the virtual machine. However, because threading is an optional feature, the minimal core Object class does not require the various wait and notify methods. In addition, many methods of Runtime and System are not required.
Throwable, Exception, RuntimeException
These classes are included in the core API because they are also fundamental to the operation of the virtual machine. More complex methods such as printStackTrace are not required.
Boolean, Byte, Character, Integer, Short, Void
These classes are included in the core API because they are fundamental and generally useful to most programmers writing in the Java language. These classes are subsetted to only the most necessary methods and fields.
These classes are included in the core API because they are fundamental and generally useful to most programmers writing in the Java programming language. These classes are subsetted to only the most necessary methods and fields.
This class is included in the core API because a few of its methods are generally useful to most programmers writing in the Java programming language.
BitSet, Dictionary, Enumeration, Hashtable, Vector
These classes are included in the core API because they are generally useful to most programmers writing in the Java programming language.
After getting the basic system to run, we started studying space-efficient optimization techniques to improve the performance of the virtual machine. We also started implementing a subset of the libraries that would be compatible with the standard libraries but would have a substantially smaller memory footprint.
We decided that AWT (because of its size) is not appropriate for all embedded platforms. Instead, we took advantage of native platform support for I/O and graphics.
Graphics are currently implemented by calling platform-specific graphics functions. There is no support for AWT, Project Swing, or any other high-level graphics libraries.
Another space-reducing tactic was implementing the KVM in C. However, we also minimized the number of C runtime functions that the virtual machine calls in order to ease implementation or replacement of those functions. If any of the debugging modes in the source code are enabled, then the target platform must support the fprintf function in the standard C I/O library ( stdio), or a function with the same interface as fprintf.