Re: JNI Performance

[Bryce McKinlay <bryce at mckinlay dot net dot nz>]

On Oct 28, 2003, at 12:18 PM, Tom Tromey wrote:

> Bryce> Incidentally, JNI calls seem to be at least 10X
> Bryce> slower than the JRE (for java->native calls, which this patch 
> doesn't
> Bryce> effect). I imagine that speeding JNI up would help SWT and AWT
> Bryce> significantly.
>
> I assume you mean a call from java code to a native method implemented
> as JNI.  How did you measure this?  I'd guess that the first such call
> to a given method would be very slow, then faster on the second call,
> after we look up and cache the pointer.
>
> If we're still slow after that, then that is interesting.  We generate
> stubs here that shouldn't be too inefficient.  I wonder what we could
> do differently.

I took a look at it. One obvious problem is that we allocate during 
every JNI call, in _Jv_GetJNIEnvNewFrame(). Surely the JNI_LocalFrame 
can be stack allocated? We can always expand it to the heap if it gets 
full. In fact, the comment in _Jv_JNI_PopLocalFrame seems to indicate 
that it is stack allocated, but I don't think that happens.

Other ideas for speeding it up: Use the new thread-local storage 
support to cache the thread's JNIEnv, and avoid the call to get it in 
the common case. Also, we may be able to inline the common cases of 
_Jv_JNI_PopLocalFrame.

I'll file a "JNI Performance" PR.

Regards

Bryce.