On Jul 11, 2005, at 12:14 PM, Tim Ellison wrote:
Recently, within IBM, we have been defining the interface between
IBM's
class library and the J9 VM. We deliberately haven't looked at the
GNU
Classpath/VM interface specification.
The principal goals are to enable the class libraries to be hosted on
different versions of a virtual machine, and potentially different
virtual machines, without sacrificing performance or introducing
complexity. In our design, this results in a number of class types
being (architecturally) labeled as 'kernel classes'. Kernel
classes can
be thought of as part of the VM and have to be written by the
VM-provider. With a thoughtful set of kernel classes the API from
class
library to the VM, and from VM to class libraries, can be kept
remarkably small. Our complete VM/Classlibrary interface comprises a
short C header (vmi.h), about 18 classes defined by 1.4 public API
(java.lang, java.lang.reflect, ...), and two classes that are
specifically to support the interface. We are working on necessary
extensions to this interface for 1.5.
what is in the two classes that are needed to support the interface?
IOW, what functionality is needed?
If there is an interest, we can share the interface we are using and
evolve it as part of harmony. It would be great if we could share
experiences with the GNU Classpath VM interface in such a way that the
Harmony interface was suitable for the widest variety of VMs and class
libraries.
Regards,
Tim
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
Archie Cobbs wrote:
Geir Magnusson Jr. wrote:
Ok, from the school of "Storming the Gates! Take 2", lets again
examine the question of VM/classlib interface as this is an
important aspect to address and our first run at it wasn't so
successful.
The questions I have are all around the different ways has this
been done. So far we know about GNU Classpath, but I assume
there
are others. What I'm specifically interested in is :
- what were the architectural goals
- what mistakes made in the past did you try to avoid
- what are the known limitations
- does the interface support our target version of 1.5
Just my opinion: I don't think the VM/classlib API matters that
much.
Seriously... I've never done VM work, but system-level work that I
have done can live or die based on the API, for all sorts of
reasons,
like performance, the ability to elegantly evolve over time, etc.
I think you're right -- in general -- that API design can have a
major
impact on things. I'm just saying that in this specific case it
doesn't
look like it's so critical (to me).
The API is private to the VM implementation, so the only effect
it can
have on application code is how efficient it is.
The API isn't private to the VM implementation, is it? The
_implementation_ of the API is, but not the API itself - that's a
contract between the classlib and VM...
You're confusing two things: the API that applications use (which
is strictly a Java API you can read about via Javadoc) and the API
that the class library uses, via native method calls, to talk
directly
to the VM. The latter is not publicly visible (and usually VM
specific).
Now, there may be public methods such as Thread.start() that just
happen to be implemented via native method calls directly into the
VM, but those are degenerate cases. The application doesn't "know"
that things happen to be implemented that way and that it might be
making a direct native call into the VM.
By the way, Classpath avoids any such degenerate cases: all methods
in class Foo that could be native instead are called through a
"liason" class VMFoo. So all of the Classpath/VM API native methods
are non-public. (This is why I said Classpath assumes the VM can
do "easy" inlining, because of the Foo -> VMFoo extra hops).
The API that applications use is defined by the public classes and
methods in the class library. How those classes are implemented is
not known to the application (and the application shouldn't care).
Which ones actually involve calls into the VM is irrelevant.
E.g., have you ever seen the Javadoc for a method contain the
"native" keyword? No -- that keyword is stripped out because it's
irrelevant from an API point of view (so is "synchronized").
Instead, those are implementation details.
The application just sees a big Java class library. The class library
sees a handful of native methods into the VM. The VM sees an
operating system of some sort. Etc.
For example, when people were porting their platforms to use GNU
Classpath's API, what did they think? Did they have to redo
anything
internally?
In my experience, things mostly made sense, but there were definitely
some problems. However, they were there more because nobody had
gotten
around to fixing them, rather than some conflict of API design vision
or anything like that.
For example, the API call to load native libraries didn't have a
ClassLoader parameter. But that is required to properly implement
Java 2 style class loading (and unloading). So we added one. There
was nothing controversial about it. Similarly for lots of other
stuff.
In other words, there hasn't been much debate on the Classpath lists
about APIs. It's pretty straightforward, and in for the most part the
little details don't matter that much anyway. This is why many of
us who
work on Classpath are wondering why anyone would bother wondering how
to reinvent the wheel, when the wheel already rolls just fine :-)
Cheers,
-Archie
_____________________________________________________________________
_____
Archie Cobbs * CTO, Awarix * http://
www.awarix.com
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
