GNU Classpath VM Integration Guide
John Keiser
C. Brian Jones
Table of Contents
The Classpath Project's ambition to be a 100% clean room implementation
of the standard Java class libraries cannot be fulfilled without some
level of integration with the Virtual Machine, the underlying machinery
that actually runs Java.
There are several VMs out there, here is a small list.
- Japhar
Japhar was the first VM to use GNU Classpath. Today you can see that
sort of relationship in the source tree which denotes several Japhar
specific files as a reference implementation of those pieces. This VM
has been primarily tested against Linux and lacks garbage collections, a
JIT, and suffers recently from slow development.
- Intel's Open Runtime Platform
Intel surprised us not long ago with the release of this rather advanced
VM that uses GNU Classpath for a set of class libraries and works on
Linux and Windows 2000.
- SableVM
The goal of this project is to build an efficient Java virtual machine
in C for the GNU/Linux operating system. SableVM implements the Java
virtual machine specification, second edition, and like the Intel VM
includes a special version of the GNU Classpath libraries.
- Kaffe
Kaffe is an advanced VM and together with its own class libraries
provides a Java 1.1 compatible environment.
- Electrical Fire
The Electrical File VM continues to be listed as a Mozilla project
though development has been somewhat quiet. A number of concepts from
EF were expected at one point to be rolled into Japhar, but that
development has not occured as of yet.
- LaTTe
This VM project so far supports only Sun UltraSparc processors using the
proprietary Solaris 2.5.1 or higher operating system. LaTTe was derived
from Kaffe but claims a number of improvements.
Current integration efforts are focused mainly on Japhar with an eye
towards getting Electrical Fire to work. All information contained in
this document is gleaned from these efforts.
The order of initialization, as far as I can tell, doesn't matter just
yet. However, when we move to 1.2 support, it probably will matter, so
we'll have a note in here at that time.
Several core classes must be implemented by the VM for Classpath to
work. These classes are:
- java.lang.Class
- java.lang.Runtime
- java.lang.Thread
- java.lang.Throwable
- java.lang.reflect.Constructor
- java.lang.reflect.Method
- java.lang.reflect.Field
You also need to implement some helper classes in java.lang that classes
from Classpath call out to to get certain VM-specific dirty work done:
- java.lang.VMObject
- java.lang.VMClassLoader
- java.lang.VMSystem
- java.lang.VMSecurityManager
Some of the classes you implement for the VM will need to call back to
package-private methods in Classpath:
- java.lang.ThreadGroup.addThread(Thread)
Call this method from Thread when a new Thread is created, to add it to
the group.
- java.lang.ThreadGroup.removeThread(Thread)
Call this method from Thread when a Thread is stopped or destroyed.
VMs need to do some dirty work; there are some things in the VM that
unfortunately are dependent on the internal structure of various
classes. This is a guide to all of the things the VM itself needs to
know about classes.
- java.lang.Class
You, the VM, get to create this Class, so you may define the internal
structure any way you wish. You probably have code somewhere to
translate your internal class structure into a Class object. That is
the only known place where this matters. Some VMs do not create the
Class object at the point where the class is defined; instead, they wait
until a Class object is actually used.
- Array Classes
When you are creating an array class, you should set the ClassLoader of
the array class to the ClassLoader of its component type. Whenever you
add a class to a ClassLoader, you need to notify the ClassLoader and
add the new Class to its internal cache of classes. To do this, call
ClassLoader.addVMCreatedClass(Class). Note: this is written in
anticipation of 1.2 support and does not apply just yet.
- Primordial Class Loader
When the primordial class loader loads a class, it needs to tell
Classpath what it has done in order for security stuff to work right.
To do this, call the static method
ClassLoader.newPrimordialClass(Class).
Even the first few core classes need to do this; in order to do it,
simply call this method after the initial class loading has been
done. No harm will come, as long as you follow the guidelines in the
see section Initialization section.
Note: this is written in anticipation of 1.2 support and does not
apply just yet.
- java.lang.Throwable (Classpath 0.02)
The VM may choose to implement this class in whatever fashion it would
like. If you choose to use the reference implementation, then you must
define two functions within some library and change Throwable.java to
load your library. The two functions are printStackTrace0(Object), and
fillInStackTrace().
- Top-level Exception Handler
Exceptions take care of themselves in Classpath; all you need to do in
the top-level exception handler is call Throwable.printStackTrace().
XXX I think this was a bad design on my part. It takes up memory and
CPU cycles that do not need to be taken up for exceptions which are
simply caught. This portion of the VM interface will be changed so that
VMs must associate native stacktrace data with the Throwable itself or
even do some sort of lazy stacktrace information addition to the
Throwable, only copying stacktrace data as it is lost (as functions are
exited) to preserve memory and cycles. The usual case is the one where
an exception is caught. The top-level exception handler is, well, an
exception among exceptions.
- Security and Traces
There will eventually be a feature in the 1.2 security that keeps the
AccessController from having to evaluate all of the
ProtectionDomains every time a security check is made. I think a common
case is a single method doing a lot of things that require security
checks. However, I don't want to bog down the method stack too much, so
this feature of the VM will have the AccessController for a thread
calling out to the VM to tell it how high it was on the stack when it
made the last security request. Every time the stack goes lower than
that number, the VM will decrement the number. The AccessController
will remember what the accumulated protection status was at every stack
level (an AccessControlContext) and use that aggregated information to
do the check. I am not sure, however, whether the savings are
substantial enough to outweigh the integer check and set after every
method call. I will investigate.
- Threading
I figured I'd put this here because a VM guy might be wondering about it.
We implement ThreadGroup, but that class is almost entirely
VM-independent. The root ThreadGroup, a static field called
ThreadGroup.root, should be initialized by Classpath, but if you wish to
reinitialize it yourself, there should be no harm.
This document was generated on 6 January 2001 using the
texi2html
translator version 1.54.
Return to GNU's home page.
Please send FSF & GNU inquiries & questions to
gnu@gnu.org.
There are also other ways to
contact the FSF.
Please send comments on these web pages to
webmasters@www.gnu.org,
send other questions to
gnu@gnu.org.
Copyright (C) 1999 Free Software Foundation, Inc.,
59 Temple Place - Suite 330, Boston, MA 02111, USA
Verbatim copying and distribution of this entire article is
permitted in any medium, provided this notice is preserved.
Updated:
06 Jan 2001 unknown