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 > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/classpath
signature.asc
Description: This is a digitally signed message part
