K Virtual Machine and its architecture by R4R Team

K Virtual Machine and its architecture:

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:

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

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.

KVM Platform Debug Architecture:

Based on existing JDWP (Java Debug Wire Protocol)
Memory-intensive operations moved to Debug Agent (aka Debug Proxy) on Desktop Workstation
KVM implements subset of JDPW command set (KDWP)


Write once, run anywhere:

Overall, I am impressed by the J2ME concept and the KVM implementation. Some initial concerns about garbage collection were addressed in release 1.0.3. And, though the new collector is not deterministic, it is far more responsive and respectable than its predecessor.

One remaining complaint concerns the threading model, which has yet to be improved in any update. Under KVM, each Java thread executes a fixed number of bytecodes before being preempted by the scheduler. This overly simplistic round-robin approach needs to be replaced by a priority-based preemptive scheduler to make KVM more than just a platform for experimentation.

Additionally, the virtual machine enhancements suggested in the Real-Time Specification for Java (link is external) would greatly enhance the value of KVM to real-time developers. Some of the proposals address determinism, others garbage collection and thread scheduling. Perhaps now that KVM's source code is out there, a helpful individual or group will come along and make these changes for the benefit of all.

In summary, KVM represents something close to a JVM embedded programmers could live with. There are still some issues of efficiency and determinism to deal with, but those are not of universal concern. By putting the trade-offs of size vs. portability in the hands of the developers-and in the process, minimizing insistence on portability at all cost-Sun has given us a very nice way to run Java programs on simpler processors with far less memory than ever before. And J2ME's configurations and profiles provide a flexible roadmap for achieving a desired level of portability at a more reasonable cost.