Cleanly defining the VM interface

[David Holmes]

Just some feedback from someone trying to integrate Classpath into a
VM.

The interface between the Classpath classes and the VM needs to be
clearly and consistently defined. At present there are three ways in
which the VM can/must provide functionality expected by Classpath:

a) implementation of the core classes like Thread, Runtime etc as per
the vm/reference tree

b) implementation of VM-specific classes, like VMObject, VMSystem etc,
in terms of which other Classpath classes are written

c) native methods (that may or may not have a general implementation
in terms of JNI/CNI)

Unfortunately how the choice of making a class part of the core that
the VM must implement, versus writing it in terms of VMxxx classes,
versus declaring it to have native methods, is made is not clear. I'm
assuming that the general intent is to do something like this:

- if it can be implemented in Java source then code it in Java source
- it it can be implemented in standard JNI calls then make it native
- if it's really VM specific then make it a call to VMxxx.foo

right?

For example Object is not a class that the VM must implement and it is
mostly written in terms of VMObject, yet it also has one native
method: getClass.

Back in September 2002, getClass was removed from VMObject and
replaced by the native call. One argument was that "Object will most
likely be reimplemented by the VM anyway". But if that was the case
then Object should be one of the core classes that the VM must define.
The general consensus however seems to be that Object is written in
terms of VMObject, hence it can be part of the mainstream Classpath
and need not be implementation specific. I'd advocate restoring
VMObject.getClass so that Object's only dependency is on VMObject and
not on the native interface. Or else make Object a class that must be
implemented and get rid of VMObject.

In our system we do not support a native interface like JNI and so
every native method is a thorn in our side (I should make it clear
that we don't intend to support all of the functionality of the Java
class libraries). Ideally we will not need to modify any of the main
Classpath classes beyond those defined in vm/reference, yet things
like Object.getClass being native  force us to provide our own
definition of Object that differs only in this one regard. From our
perspective there should be no native methods in the main Classpath
classes but only calls to VMxxx methods, which then may be native.
This additional indirection would make it easier to adapt classpath to
VM's without JNI. I realize this may conflict with the general view.

Additionally there are some undocumented dependencies between the main
Classpath classes and the "reference implementations" in vm/reference.
Such as direct access of fields in Runtime. These dependencies either
need to be documented clearly or removed. I'd advocate removal as most
seem to be premature optimisations.

The initialization sequence all needs to be looked at. In particular I
think it a very bad idea of have static initializers in class Class
that cause a mass of initialization to occur - as in the reference
implementation. Class is the first class to be initialized (in the
sense that you need a Class object for any class before you can
initialize it, and to get a Class object class Class must be
initialized) and so you don't want it to do anything non-trivial in
static initializers. Beyond that some clear and up to date description
of the initialisation process would be good.

But overall - keep up the good work. :)

Cheers,
David Holmes