harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@apache.org>
Subject Re: [arch] VM/Classlibrary Interface (take 2)
Date Mon, 11 Jul 2005 18:17:15 GMT

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

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org



Mime
View raw message