JNI-performance - Is it really that fast?

steve goldman Steve.Goldman at Sun.COM
Tue Mar 25 13:30:02 UTC 2008

Dmitri Trembovetski wrote:
>   Some members of the Java2D team would incline to
>   respectfully disagree with the assessment that JNI is
>   "that" fast =)

I was really enjoying this thread even though I knew that someone from 
J2D was going to burst the bubble. :-)
>   Jim Graham wrote an extensive JNI benchmark (which tests method calls
>   with different types/number of arguments, Get/Set methods,
>   GetPACritical, etc), and ran it against multiple Java releases.
>   We have an internal page with the results. Unfortunately we don't
>   have the bandwidth to get the benchmark out.
>   The net result is that while the jni performance had improved
>   over the years (the amount of improvement varies
>   from platform to platform) it is still not satisfactory
>   in many areas. Our per primitive cost is still mostly
>   consists of jni overhead for small primitives (think
>   fillRect(1x1)).

As a warning to people writing jni benchmarks. It is very easy to write 
a bad microbenchmark that tries to measure the overhead of calling a 
native method on sparc. Because of the register window flush we must do 
when we transition to native if your microbenchmark (or app for that 
matter) consists of a loop that repeatedly calls a jni method that does 
very little work (e.g. no other calls) then a large portion of the work 
is window flushes. I could believe there are parts of J2D that could 
look like that and the changes to how safepoints were done in Java 5.0 
that changed the window flush strategy is painful for that type of code. 
The benchmarking the jvm team did showed that most code doesn't look 
like that and the flush was not so painful. Platforms without register 
windows don't suffer from this in any case.

I do have some changes (which Jim has benchmarked) that improve jni 
performance a bit more across all the platforms and mostly remove the 
microbenchmark pothole on register windowed machines. At this point the 
changes only work for server and aren't really ready for primetime. 
Someday I hope to get back to them.

In the meantime the people who believe jni performance is very good 
please continue to speak up as I'm sure the vm engineers who have worked 
to improve this path over the years will appreciate the feedback. :-)


More information about the discuss mailing list