harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [arch] VM/Classlibrary Interface (take 2)
Date Mon, 11 Jul 2005 16:14:39 GMT
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.

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 (t.p.ellison@gmail.com)
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
> 


Mime
View raw message