Hi Mladen,
I am curious about 'light-weight' native calls for primitive array
type you mentioned below. In the general case, a GC might move the
primitive array while the native method is operating on the array.
Can you tell us how the light-weight interface would deal with this
situation? Does the array need to be pinned before calling the
light-weight native?
Another approach is to disallow GC for the duration of the native
method. I think this works as long as there are guarantees on the
maximum duration of native method execution and the native method is
not allowed to call another java method. The java method called from
the native method might execute an object new which, in turn, might
cause the GC to collect. Of course the GC can't collect because there
is a light-weight native method on the stack that won't allow it.
There might also be similar sorts of issues with a light-weight native
method throwing a java exception.
It woudl be great if you could provide us with more details on your
native method interface ideas.
Thanks
Weldon
On 7/11/05, Mladen Turk <[EMAIL PROTECTED]> wrote:
>
> 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.
>
--
Weldon Washburn
Intel Managed Runtime Division
