harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Archie Cobbs <arc...@dellroad.org>
Subject Re: [arch] VM/Classlibrary Interface (take 2)
Date Sun, 10 Jul 2005 21:21:59 GMT
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.

The API is private to the VM implementation, so the only effect it can
have on application code is how efficient it is.

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.

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)).
2. Keep the API reasonably easy to understand.
3. Don't worry about inlining Java code: assume the VM can do 'easy'
    inlining like invoking static methods.

Again, just my opinion.


Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com

View raw message