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 12:48:38 GMT

On Jul 10, 2005, at 5:21 PM, 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.
>
> Rather, what's more important is making the runtime transitions  
> into and
> out of the JVM (i.e., through this API) seamless. This is mostly a
> property of the VM implementation rather than the API design.

Hm.  I'm not sure if I agree, as I can think of some really awful  
APIs between the VM and the classlibrary.  XML, for example...

    public String exec(String xmlInput)

(wait, that's the semantic description of webservices, isn't it...)

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.

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

>
> Classpath has defined a reasonable API. I can't imagine how  
> rearranging
> the API dramatically would make things noticably better, either in
> performance or code clarity/maintainability.

That's just the question I'm interested in exploring.  I'm not  
starting out with an predetermined answer, but rather know that there  
are others in the universe that have thought about this, and am  
interested in what they think.

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?

>
> Can't comment on the 1.5 aspects, but the design goal of Classpath
> seems to have been a combination of:
>
> 1. Make the set of VM native calls not too far from the minimal
>    possible set (i.e., don't add native methods for things that can
>    be done fairly easily in pure Java (plus other native methods)).

yep - that makes sense.

> 2. Keep the API reasonably easy to understand.

yep

> 3. Don't worry about inlining Java code: assume the VM can do 'easy'
>    inlining like invoking static methods.

How does that aspect matter to the VM/classlib interface?

geir

>
> Again, just my opinion.
>
> -Archie
>
> ______________________________________________________________________ 
> ____
> Archie Cobbs      *        CTO, Awarix        *      http:// 
> www.awarix.com
>
>

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



Mime
View raw message