JNI Performance

Sat Nov 8 02:00:00 GMT 2003

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.