Patch: JNI stubs for gcj

Fri Apr 21 07:27:00 GMT 2000

Per> It looks like we call _Jv_LookupJNIMethod for every call to a JNI
Per> method. That seems rather expensive. I assume you've thought
Per> about caching? The ideal would be a "thunking" solution: We have
Per> a static pointer to the JNI function, which is initialized to
Per> something that calls _Jv_LookupJNIMethod.
I've been playing with this but I'm having problems getting gcc to
make a static variable for me. Unfortunately the only way to learn
about trees sems to be to read the other front ends, which is rather
inefficient.
Per> Of course for best performance you want to resolve the actual JNI
Per> function statically. The requires searching the .so file(s) for
Per> the appropriately-mangled symbols, so it may be best done at link
Per> time.
This definitely won't happen in the short term.
Also, if we have caching, it isn't clear that this approach would
really be much faster. I think it would only be faster in the case
where we call a large number of JNI functions one time each.
Tom