harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mladen Turk <mt...@apache.org>
Subject Re: [arch] VM/Classlibrary Interface (take 2)
Date Mon, 11 Jul 2005 17:16:29 GMT
Geir Magnusson Jr. wrote:
> 
>    - 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
> 
> Anyone who has experience, please post it here, describing the  
> particulars rather than just point someone to docs or code that may  be 
> under a license not acceptable by everyone.  That said, please  include 
> any references too...
>

The major problem is the way how the native OS abstraction layer is
called. JNI is used as a single native interface from the ground up
and didn't change much for all those years.

For example all JVM's when calling the simple C function:

class Foo { native int add(int x, int y); }
...
int add(int x, int y) { return x + y; }

Are actually calling the:
jint Java_Foo_add(JNIEnv *env, jclass cls, jint x, jint y)

For that native 'add' you have to write a wrapper function, etc...

I propose that we add 'light-weight' native calls that will
enable to directly call the native method that doesn't need to
interfere with the JVM because they return and consume the atomic
parameters.

Further more, the same can be done for the primitive array type.

All this would require additional markup for native functions that can
be set by adding the 'RegisterNativesEx' to the JNI interface and
thus preserving the existing language spec.


Mladen.

Mime
View raw message