Patch: JNI stubs for gcj

[Per Bothner]

Tom Tromey <tromey@cygnus.com> writes:

(A great step forwards towards JNI csupport!) 

> +  /* One strange way that the front ends are different is that they
> +     store arguments differently.  */

Something for the TODO list: Fix the class-file-parsing front-end to
generate a tree node representation for the entire method, not just
for sub-expressions.  This should be easier now that Gcc can handle
fention-level tree representation for C and C++, as well as the
Java-source-parser; we should do the same the class-file-parser.  This
would clean up things like this and make various optimizations easier.

> +  /* We call _Jv_LookupJNIMethod to find the actual underlying
> +     function pointer.  _Jv_LookupJNIMethod will throw the appropriate
> +     exception if this function is not found at runtime.  */
> ...
> +  /* Now we make the actual JNI call via the resulting function
> +     pointer.    */

It looks like we call _Jv_LookupJNIMethod for every call to a JNI
method.  That seems rather expensive.  I assume you've thought about
caching?  The ideal would be a "thunking" solution: We have a static
pointer to the JNI function, which is initialized to something that
calls _Jv_LookupJNIMethod.

Of course for best performance you want to resolve the actual JNI
function statically.  The requires searching the .so file(s) for the
appropriately-mangled symbols, so it may be best done at link time.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/