RE: Classpath build process and VM-specific issues

[David Holmes]

Archie Cobbs wrote:
> - I avoid VMFoo instances (i.e, shadow objects). It seems to me that
>    storing VM specific info in a shadow object serves no (runtime)
purpose:
>    if it can be represented in Java, store it in the original object,
>    if it can't store it in a native C structure or whatever.

But just because it can be doesn't mean it will be. Having VMFoo classes
allows the VM to choose whether to implement in Java or natively. If you end
up using native then sure you have one extra level of indirection. But when
you don't use native then a native method forces an extra level of
indirection to "un-natify" it. We have very few native methods in OVM, at
the "application" level.

If performance is such a concern then specialise the Foo class directly, or
else deal with it via inlining. I think Classpath should focus on general
utility and ease of adaptation rather than raw performance - at least until
we get to Classpath 2 or 3 :)

I prefer to see a VMFoo class with native methods, than a Foo class with
native methods.

> - I used the type byte[] for all vmData fields.

We use an Opaque type to hold references to VM objects. The only use of
these references is to pass them back into the VM for action.

> - My Thread class uses private objects to implement sleep() and join()
>    in terms of Object.wait(). The VM notify()'s this object when the
>    thread exits. This means all the complexity of sleeping (and handling
>    Thread.interrupt()) can be put   in Object.wait() and not duplicated
>    elsewhere.

I do a similar thing for join().

As much as I think the Thread/VMThread split is a good attempt at a general
thread implementation it is not one that we will use for a number of
reasons. Threading is too VM specific to generalize well. Additionally we
need to customise Thread for Real-time Java support.

Just my 2c.

David Holmes