White Paper
The K virtual machine (KVM)
Share This Page
Print-friendly Version
A White Paper
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.
Table of Contents
Executive Summary
Introduction to the Java 2TM Micro Edition
-
Configurations
-
Profiles
Features of the K Virtual Machine and its APIs
-
The KVM Specification
-
The KVM Optional Features
-
The Java2 Micro Edition Core APIs
-
Basic Classes from java.lang
-
Throwable Classes from java.lang
-
Data Type Classes from java.lang
-
String Classes from java.lang
-
Miscellaneous Classes from java.lang
-
Miscellaneous Classes from java.util
Optimizations for Consumer Devices
-
Engineering a small footprint core API
Design Considerations for the KVM
-
Portability
-
Garbage Collection
-
Host System Calls
Conclusion
Executive Summary
Over the last two years Sun has introduced tailored JavaTM virtual machine technology to serve products in the consumer and embedded markets. With
PersonalJavaTM technology targeted at screen phones, high end PDAs and set top boxes, and
Java CardTM technology targeted at smart cards, Sun has greatly extended the scope of the Java programming environment. In the process, Sun has demonstrated the versatility of this environment and enabled the development of many new and powerful information appliance products. 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.
Introduction to the Java 2 Micro Edition
The
Java 2 Micro Edition encompasses the full range of products, technology, tools and standards needed to enable the information appliance market. It currently includes two different implementations of the Java virtual machine:
- A Java virtual machine suitable for 32-bit RISC/CISC/DSP microprocessors and a few megabytes of working memory. Typical products in this market include screen phones, set-top boxes and high-end PDAs.
- A Java virtual machine suitable for 16-bit or 32-bit RISC/CISC microprocessors with a few hundred kilobytes of available memory. Typical products in this market include cell phones, low- to mid-range PDAs and low-end set-top boxes.
Because Java 2 ME includes both in-device and off-device elements, it provides an end-to-end architecture for device manufacturers, service providers, and independent software vendors. The end-to-end architecture leverages and integrates such key Sun technologies as
JiniTM and
Java Embedded ServerTM.
Configurations
The Java 2 Micro Edition can be deployed in multiple configurations. A configuration is defined as a set of optimized Java APIs, class libraries and a virtual machine targeting a family of devices with similar requirements on size and capabilities. Configurations include components of the java.io, java.net, java.util, and the java.lang packages. 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.
Profiles
An additional way of specifying the subset of Java APIs, class libraries and virtual machine features that targets a specific family of devices is the profile. 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.
Features of the K Virtual Machine and its APIs
This section describes the K virtual machine (KVM). It also describes the classes and methods included in the Java 2 ME API. Although the latter topic is not strictly a component of the KVM technology, it is essential to understand how the KVM is applied in resource-limited products.
The KVM Specification
The KVM evolved from a research project at Sun Laboratories. It is a derivative of The Java Virtual Machine Specification, written from scratch in C, with special emphasis in these key areas:
- Optimized for small size
- Easily portable to different platforms
- Modular and extensible
- Source code base written from scratch
- As "complete" and "fast" as possible without significantly increasing footprint.
Except for the differences indicated in the following section, the KVM is identical to the Java virtual machine as specified in
The Java Virtual Machine Specification (Java Series) by Tim Lindholm and Frank Yellin (second edition, Addison-Wesley, 1999).
The KVM Optional Features
The KVM is designed to support standardized, incremental deployment of Java virtual machine features and Java APIs called for by the Java 2 ME architecture. The KVM specification identifies several optional features which can be omitted from some minimum initial device configurations, depending on the features and capabilities of the device. The Java 2 ME architecture includes a small number of configurations that are specified and standardized by Sun. The KVM specification gives the guidelines that Sun uses in defining configurations. It spells out exactly which features can be omitted from an initial configuration. 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:
- The applications designed for a particular configuration (or class of device) do not need the feature.
- Elimination of the feature significantly reduces memory footprint or enables some other cost savings or necessary functionality in the class of device targeted by that configuration.
While these features are optional at the KVM architectural level, they may be required at the KVM implementation level. Each Java 2 ME configuration specifies whether or not each optional feature is included. Any KVM implementation claiming to support a particular configuration must implement all the features required by that configuration. Features not explicitly identified in the following list are required and must be implemented in all configurations.
- Large data types: long, float, and double -- many configurations do not need the extended range and precision of the larger data types.
- Multi-dimension arrays -- many configurations do not need to support arrays of more that one dimension.
- Class file verification -- some specified configurations may not need to support on-device verification of class files. Instead technology is planned to be developed to enable class files to be efficiently verified "off-line" and delivered to the device.
- Handling of Error classes -- when the Java virtual machine encounters a serious internal problem, it throws an instance of a subclass of java.lang.Error. However, because there is often no reasonable form of programmatic recovery from these errors, a configuration may specify the KVM to halt with a configuration-defined error indication. Or the configuration may allow device vendors to define device-specific behavior and recovery actions when it encounters such conditions.
- Threads and event handling -- some configurations may require a different application execution model from the standard Java technology-based model using the Thread class and standard event handling.
- Java Native Interface (JNI) -- many configurations might not need the flexibility of the JNI for the way in which native methods are linked and invoked. A configuration may use a defined alternative, simpler mechanism to invoke native methods.
- Class loaders -- many configurations might not need the full flexibility of Java class loaders. A configuration must specify the mechanisms by which classes are located and loaded into the KVM.
- Finalization -- many configurations do not need to support object finalization.
- Maximum size limitations -- many configurations do not need to support the full range of sizes of internal virtual machine data structures. A configuration may specify a "maximum supported" range for some or all of the following values:
- The number of classes in a package
- The number of interfaces implemented by a class
- The number of fields in a class
- The number of methods in a class
- The number of elements in an array
- The number of bytes of code per method
- The length of a string in a CONSTANT_UTF8 constant pool entry
- The maximum amount of stack that a method may use
- The maximum number of locals that a method may use
- Start-up -- each configuration must specify how the KVM locates the initial class and method to execute and the expected attributes of that class and method.
The Java2 Micro Edition Core APIs
The Java 2 Micro Edition specifies a core set of APIs. These are required by all configurations and, therefore, must be supported by all K virtual machines. In addition to this minimum subset, every KVM must also support whatever APIs are specified by its configuration. 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.
Basic Classes from java.lang
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 Classes from java.lang
Throwable, Exception, RuntimeException and all its subclasses. 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.
Data Type Classes from java.lang
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.
String Classes from java.lang
String, StringBuffer 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.
Miscellaneous Classes from java.lang
Math 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.
Miscellaneous Classes from java.util
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.
Optimizations for Consumer Devices
The KVM technology team had the goal of building a smaller Java technology-based system. We started by building a straightforward, small, and consistently written bytecode interpreter. The developers of the KVM technology took the "blank slate" rather than the "full tablet" approach to building a smaller Java virtual machine. Beginning with the complete JDKTM technology and then removing the parts that were not needed would not have worked well since much of the standard JDK is too big to fit on a memory-constrained platform. Instead, we started with a blank slate and then added only what was absolutely necessary. This approach made it easier for developers on the team to discover dependencies in an incremental fashion and deal with them appropriately. 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.
Engineering a small footprint core API
In order to create a scalable, minimal footprint system, much work has gone into optimizing the implementation of the Java 2 ME core API. The team removed dependencies between classes whenever possible. We also employed a few simple techniques to shrink the class libraries dramatically:
- Because our implementation is performance-oriented, we removed the option to use alternate forms of functions. For example, String(char[]) is simply a call to String(char[], 0, ). Note that, with smart inlining in a performance-oriented implementation, much of the overhead of these forms is eliminated.
- We eliminated seldom-used classes or classes that can be added by the user if necessary, such as ThreadGroup.
- We avoided classes that create many short-term objects, such as Point. Instead of using Point objects, we simply used x and y coordinates as parameters.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.
Design Considerations for the KVM
Our design goal for the KVM was to have a small memory footprint without loss of performance. Therefore, we implemented around a straightforward bytecode interpreter with some optimizations of the Java virtual machine. The representation of the internal structures is conventional in the sense that each class has a constant pool, method table, field table, and interface table. However, most of the structures have been implemented as linear tables to provide faster access and to conserve memory space. We have also taken advantage of various low-level features of the C programming language to achieve better performance.
Portability
Portability was another important goal in the KVM design. For this reason, non-portable code elements (including functions that obtain information about the host computing system) have been minimized and limited to a single file. Multithreading and the garbage collector have been implemented in a completely platform-independent fashion. Rather than relying on external interrupts, the multi-tasker performs thread switching on the basis of the number of bytecodes the current thread has executed, making thread switching more deterministic and easier to debug. This approach is practical because we are not targeting multiprocessor platforms.
Garbage Collection
We provided a simple, non-moving, single-space mark-and-sweep garbage collector. It operates well with heap sizes of just a few tens of kilobytes. The collector is handle-free, because we always used direct rather than indirect object references.
Host System Calls
To minimize memory usage, we implemented the native functions and wrappers used to call host system functions - which would ordinarily be implemented through the Java Native Interface - by making them a part of the virtual machine. Currently, the native function support is very limited. 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.
Conclusion
As we move into the future our goal for the KVM technology is to evolve the K virtual machine and to provide tools to accomplish the following goals:
- Optimize class file format to reduce space requirements and to reduce time to install on the device.
- To provide other space and performance optimizations.
- To trim other "generally useful" packages (like java.net and java.io) so that they will fit better, and so that profiles can optionally specify them.
- To produce a lightweight JNI capable of running on the small footprint of KVM technology.
- To produce a KVM capable of supporting consumer JiniTM connection technology client code.
- Sun will work with vendors and content providers to develop optimal APIs for a variety of application profiles.
- To support application development done on workstations using standard Java development tools. Then, after the code is compiled and a Java technology-based classfile is generated, the classfile would be passed through a converter designed to support the needs of a particular application profile. The converter would optimize the bytecode to fit within the small footprint of an embedded device, and convert bytecode to run in the virtual machine within that embedded device.
Banned
Sabayon Linux x86-64 3.25 DVD 2007-01-02 01:45:21
Originally Posted by Rodneyck
Is there a way to just do an update from a 3.2 disk to a 3.25? I really do not want to download another DVD iso...
Posting Permissions
Adv Reply
Bookmarks