[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposal for changes to Classpath's JNI libraries

From: John Leuner
Subject: Re: Proposal for changes to Classpath's JNI libraries
Date: 03 Dec 2002 18:55:38 +0000

An interesting idea. It would remove the need to modify the JNI table.

I assume there would then still be JNI native methods for the IO
functions, and each of these would delegate to some special function?

John Leuner

On Tue, 2002-12-03 at 18:17, Artur Biesiadowski wrote:
> 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
> _______________________________________________
> Classpath mailing list
> address@hidden

Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

[Prev in Thread] Current Thread [Next in Thread]