Re: JNI Performance

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Bryce" == Bryce McKinlay <bryce@mckinlay.net.nz> writes:

Bryce> I took a look at it. One obvious problem is that we allocate during
Bryce> every JNI call, in _Jv_GetJNIEnvNewFrame(). Surely the JNI_LocalFrame
Bryce> can be stack allocated?

Oh, yeah, I forgot about that.  Sure, I think we could make this
change.  Some parts of our JNI implementation are horribly slow, like
the local reference support.

There is a sort of open question about binary compatibility and
low-level calls.  Our JNI stubs make direct calls into libgcj.  So
does java code, e.g. we generate direct calls to _Jv_Throw.

One idea would be to have these calls also go through the otable.
This would mean having some way to describe the standard bits of the
libgcj API that we need to expose (it looks scarily like JNI :-).

Then if we change the API we could keep a backward-compatible
interface around...

Bryce> In fact, the comment in _Jv_JNI_PopLocalFrame seems to indicate
Bryce> that it is stack allocated, but I don't think that happens.

That must be left over from some earlier version of this code.  Oops.

Bryce> I'll file a "JNI Performance" PR.

Thanks.  I'll file a "low level binary compatibility" PR.

Tom