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. :-)
--
Steve
More information about the discuss
mailing list