Re: Cleanly defining the VM interface

[Archie Cobbs]

David Holmes wrote:
> 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:

As another recent VM implementor working with Classpath, I agree
with your comments, though as somebody pointed out things are
slowly changing to make the classes<->VM interface more consistent.

When I first started I also wanted a cleaner and better documented
interface based solely on the "VMFoo" class idea.

However, since then I've come to a slightly different opinion.. this
is just personal opinion and not intended to imply a desire to change
the current state of things, BUT... in the end I'm not sure whether the
VMFoo classes are worth it (depending on a particular VM's goals of course).

They do add a certain amount of overhead and complexity which,
depending on how much your VM cares about performance, might just
have to be reverted in the end. E.g. I merged VMThrowable into Throwable.

The VMFoo classes are great for locating all the native methods that
a VM must implement, but IMHO that could just as easily be done with
an (automatically generated?) README file that lists them all. FWIW...

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

This had me stumped for a while too. If you look at SableVM for example
it doesn't allow static initializers in Object or Class. I wanted to
support them however (to avoid having to hack on Classpath) so had to
find a way to do it.

My solution was as follows (if people think this is a resonable approach
then it would be great to document it somewhere). Here "load" means just
load (i.e., create the internal structure associated with the type); don't
resolve, initialize, etc.

 0. First, never invoke any constructors for java.lang.Class; there's no
    need to.
 1. When deriving types, if java.lang.Class hasn't been loaded yet, disable
    creating the java.lang.Class instance associated with that type.
 2. Set a flag that disables class initialization.
 3. Load all "special" classes required to be explicitly known by the VM,
    including primitives, Cloneable, etc., and java.lang.Class.
 4. Iterate through the bootstrap loader's defined types tree and create
    the java.lang.Class instance for each loaded type. Do the same for
    the primitive types (they are special and shouldn't be in the tree).
 5. Resolve java.lang.Class and java.lang.Object. This causes a bunch of
    other classes to be loaded. Still no class initialization yet.
 6. Re-enable class initialization.
 7. Initialize java.lang.Class. This also initializes java.lang.Object and
    invokes their static initializers (if any).
 8. Now you are good to go!

Step 5 is necessary because otherwise the VM will attempt to
initialize Class before (fully) resolving it (i.e., it will try to
initialize Class, which first tries to resolve it, which loads other
classes, which causes their Class instances to be created, which
causes Class to be initialized, ...)

-Archie

__________________________________________________________________________
Archie Cobbs     *     Precision I/O      *     http://www.precisionio.com