[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
> http://mail.gnu.org/mailman/listinfo/classpath
signature.asc
Description: This is a digitally signed message part
- Re: [Kissme-general] Re: Proposal for changes to Classpath's JNI libraries, (continued)
- Re: [Kissme-general] Re: Proposal for changes to Classpath's JNI libraries, Stephen Crawley, 2002/12/03
- Re: Proposal for changes to Classpath's JNI libraries, Tom Tromey, 2002/12/03
- Re: Proposal for changes to Classpath's JNI libraries, Artur Biesiadowski, 2002/12/03
- Re: [Kissme-general] Re: Proposal for changes to Classpath's JNI libraries, Etienne M. Gagnon, 2002/12/03
- Re: [Kissme-general] Re: Proposal for changes to Classpath's JNI libraries, John Leuner, 2002/12/03
- Re: [Kissme-general] Re: Proposal for changes to Classpath's JNI libraries, Etienne M. Gagnon, 2002/12/03
- Re: [Kissme-general] Re: Proposal for changes to Classpath's JNI libraries, Artur Biesiadowski, 2002/12/03
- Re: [Kissme-general] Re: Proposal for changes to Classpath's JNI libraries, Etienne M. Gagnon, 2002/12/03
- Re: [Kissme-general] Re: Proposal for changes to Classpath's JNI libraries, Stephen Crawley, 2002/12/03
- Re: [Kissme-general] Re: Proposal for changes to Classpath's JNI libraries, Etienne M. Gagnon, 2002/12/04
- Re: Proposal for changes to Classpath's JNI libraries,
John Leuner <=
Re: Proposal for changes to Classpath's JNI libraries, Brian Jones, 2002/12/08
Re: Proposal for changes to Classpath's JNI libraries, Stephen Crawley, 2002/12/03