The K virtual machine (KVM)

   

 

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 2 TM 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

TM PersonalJava TM Java Card TM

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

Java 2 Micro Edition
  • 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.
Jini TM Java Embedded Server TM

 

Configurations

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

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

 

The KVM Specification

  • 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.
The Java Virtual Machine Specification

 

The KVM Optional Features

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:

  1. The applications designed for a particular configuration (or class of device) do not need the feature.

     

  2. 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.

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

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

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

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

  • 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

 

Portability

 

Garbage Collection

 

Host System Calls

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

  • 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 Jini TM 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.
Left Curve
Java SDKs and Tools
Right Curve
Left Curve
Java Resources
Right Curve