RE: Cleanly defining the VM interface

[David Holmes]

Archie Cobbs wrote:
> 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..
> ...
> 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...

In my view the most important thing about the VMFoo classes is that
they isolate (potentially) VM-specific functionality from general
functionality so that I can modify/adapt each of them independently.
If class A in written in a general way with a few dependencies on VMA
then I don't have to worry about integrating patches to class A -
things will just work. If I had to customize class A because I wanted
to replace a native method then I have to hand integrate all
subsequent patches.

I agree that the extra level of indirection can become a performance
issue, but I think that is a second-level concern. First I want the
isolation and independence and I can get the functionality right. If
then I determine that there are performance issues then I can choose
which classes to "fold" together, and choose the accept the
maintenance burden of those folded classes.

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

Given that Class is one of the classes that the VM is expected to
implement I wasn't too concerned about "hacking" on it, but I don't
think the 'sample' Class should include any static initialization.

The actual class initialization process, as defined by the JVMS and
JLS, has a slight bootstrapping problem that seems to be left to the
VM to resolve. To initialize a class you must first lock its Class
object. But you can't have a Class object without creating one, and
instantiation is an active use of a class and so class Class must be
initialized before you create an instance. But initializing class
Class requires that you lock it's class object and that sets up an
infinite loop that you have to break somehow. I chose to remove static
initialization from Class and to simply mark class Class as
initialized. (All classes were already implicitly linked and
resolved).

My main problem with initialization is getting to a point where I can
bind the initial java.lang.Thread object to the "main" thread, as soon
as possible without invoking too many other initializers. Class
initialization inherently uses synchronization and that's a bit tricky
without a current thread. Basically, you either need to allow for and
deal with a null current thread; or you need a "magic" way to create
the initial Thread object without actually performing class
initialization. Messy either way.

Cheers,
David Holmes