This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Patch: JNI stubs for gcj
- To: Per Bothner <per at bothner dot com>
- Subject: Re: Patch: JNI stubs for gcj
- From: Tom Tromey <tromey at cygnus dot com>
- Date: Fri, 21 Apr 2000 07:27:33 -0700 (PDT)
- Cc: tromey at cygnus dot com, Gcc Patch List <gcc-patches at gcc dot gnu dot org>, java-discuss at sourceware dot cygnus dot com
- References: <87r9c0y4f9.fsf@cygnus.com><m2g0sgbl3n.fsf@kelso.bothner.com>
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