BytecodeProcessInReview.Main @ jos.sf.net

Introduction

At first, I thought a "Java Virtual Machine" from Sun Microsystems was a virtual machine. They called it a virtual machine. Others called it a virtual machine. I thought they all knew the difference between a "virtual machine" and an "abstract machine". It seems that Sun Microsystems has created an "abstract machine" after all. Their abstract machine is virtual only by virtue of a foreign operating system. A foreign operating system must provide Sun Microsystems' abstract machine with all the elements which make it virtual.

This has tripped up those of us who look for features dealing with the virtual-ness of a machine within the "Java Virtual Machine Specification" (JavaVirtualMachineSpecification). You would think that the specification would include some baseline for building the virtual part of the machine. But alas, it does not. The specification assumes the existance of a foreign operating system. You're supposed to look for all features dealing with the virtual-ness of a machine within the specification of a foreign operating system.

1. There is no mention of multiple primordial class loaders.

If the Java Virtual Machine were truly virtual, its specification would address the need for each application space to have its own primordial class loader. Instead, the specification assumes a foreign operating system will enable each instance of the abstract machine to maintain its own independent primordial class loader. If you remember, a primordial class loader enables each virtual machine to have its own static fields for system classes.

Think of it. Every time you use the java tool, you create a new primoridial class loader. Each instance of the java tool has an independent CLASSPATH. The CLASSPATH has a significant impact on the behavior of your application. It is difficult, if not impossible, to limit the CLASSPATH to a single value to meet the needs of all your Java applications. A single CLASSPATH would always prevent a Java-operating system from being self-hosting.

2. There is no mention of possible optimizations for running many virtual machines within a physical machine.

If the Java Virtual Machine were truely virtual, its specification would address the issue of share-able and unshare-able components. Many virtual machines can share common executable code. The specification assumes a foreign operating system will share common executable code. And more to the point, many virtual machines can share common bytecode. The specification assumes that there is no need to share common bytecode because, obviously, a foreign operating system will provide a virtual memory manager. Here again, it might have been better if the Java "Virtual" Machine were called what it is: the Java "Abstract" Machine.

The reference implementation of a Java Virtual Machine can be relatively un-concerned with memory consumption. A foreign operating system provides an inexhaustable supply of virtual memory. It does not matter so much that identical classes loaded with different class loaders take up more space than they should. It does not matter so much that identical classes loaded with different virtual machines take up more space than they should either.

Suddenly, it matters. On a Java-based operating system without a virtual memory manager, there is a limited supply of memory. More memory optimizations are possible and desireable.

In Summary

The effect of this on a Java-based operating system is catastrophic. When a so-called virtual machine designer thinks about building a Java-based operating system, it always looks less difficult than it really is. In order to build a Java-based operating system, we have to add all the virtual-ness to the Java Virtual Machine specification.

The pleasant, simpler alternative is this: forget about running off-the-shelf Java applications inside the Java-based operating system. Provide a single application space. Provide a single primordial class loader. Provide a single set of the four necessary threads:

main thread,
user interface thread,
finalizer thread, and
garbage collection thread.

The more challenging alternative is this: implement multiple instances of the abstract machine within a single machine. This is the recommended approach from Sun Microsystems as specified in Java Native Interface (JNI).

Otherwise, you must gather all the virtual-ness features together before you can build a virtual machine. It have taken a long time to develop these feature for other operating system. It will take a long time to develop these for a Java-based operating system. The virtual-ness features are the most difficult of all system components. They include all virtualization of hardware, including devices and memory. They include so-called multi-tasking, either preemptive or non-preemptive.

Our single biggest challenge is this: a Java-based operating system looks easy when it is not. How many people have underestimated how long it would take? how big it would be?

-- GilbertHerschberger ( 27 June 2001 )

Gilbert, I have to hand it to you; abstract vs virtual machine makes the difference between JOS and a `conventional' JVM clearer than I've ever managed. SystemArchitecture refers to the difference between a virtual system -- the hardware -- and the virtual machine -- which Java bytecodes target, where JOS provides the system and the machine. What we actually want is to define the abstract JOS system -- the JOS API -- and provide an implementation to make it the virtual JOS System.

I've been working at the University of Utah for a month now, and one of their specialties is what they call Java operating systems. While what they've been doing has been technically impressive -- particularly KaffeOS -- calling them operating systems has been grating on me for a while, and this finally helped me realize why: process and resouce control do not alone an operating system make. All their work still requires considerable support from the operating system (libraries), and they make no provision for utilising the hardware from Java.

Above, in "implement multiple instances of the abstract machine within a single machine", you mean, within a single virtual machine (process), right? After all, the abstract machine instances could be run in different, but communicating, virtual machines (processes).

As for the size and difficulty of the task, that is one of the reasons why I'm growing increasingly fond of JohnLeuner's teaseme project. It leverages the power and features of the linux kernel (or, in emulation, a linux distribution) but also runs on RobertFitzsimon's RJK, which is (appears to be) under more active development, and more featureful, than jJOS. As more of JOS is written, less of the linux kernel (and system) will be necessary, and at some point, the linux and RJK builds should converge, in terms of features used by the non-kernel parts of teaseme.

[As an aside, John: can teaseme be compiled into the kernel? (Equivalentally, can the kernel insert modules into self before init is run?) At some point, (after I (hopefully I'll do work :)) get VGA consoles working) I'd like to play with stripping down the linux kernel to the bare minimum and booting the machine with a Java process, run by teaseme, as `init'.]

-- ToddMiller ( 27 June 2001 )

Content of these pages are owned and copyrighted by the poster.
Hosted by: