This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Patch: JNI stubs for gcj


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]