Re: Proposal for changes to Classpath's JNI libraries

[Artur Biesiadowski]

Tom Tromey wrote:

> You're already going to change the native code to add special
> Kissme-only calls.  Why do these new calls need to go in the JNI
> vector?  Why not just make direct calls?  We already know that no
> other platform is going to use these new functions.

Maybe an acceptable solution for that would be to create indirection 
layer on top of all offending function (open,close,read,write,maybe few 
more) ? Classpath would require each jvm to implement one call which 
would return vector with pointers to wrapper functions, which would 
happen to have same signatures as C-ones. Trivial implementation would 
just return pointer to struct pointing to normal open/close/etc. Kissme 
could implement their read_wrapper, which would do gc magic and only 
then call libc.

Runtime and implementation cost is minimal. One or two extra pointer 
dereferences for functions like open/close or read/write are really 
nothing. Implementation burden on 'normal' jvm is also minimal - 
probably it will just mean including one page of ready code.

I'm not sure how it will look from config point of view - should 
classpath lib call jvm to get a vector, or should jvm call some kind of 
hook in classpath jni at init - this are details which can be solved.

I would also put some extra functions there - probably C-heap memory 
allocation (defaulting to malloc/calloc/free).

There is also an option of implementing entire vm-specific part on top 
of such interface - by adding some functions like getIdentityHashCode, 
runGC etc, but this is probably too big change and I'm not sure if it is 
good. But basic idea sounds good to me - what do you think ?

Artur