JNI-performance - Is it really that fast?
Dmitri Trembovetski
Dmitri.Trembovetski at Sun.COM
Mon Mar 24 22:33:33 UTC 2008
Some members of the Java2D team would incline to
respectfully disagree with the assessment that JNI is
"that" fast =)
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)).
Thanks,
Dmitri
Java2D Team
Clemens Eisserer wrote:
> Hello,
>
> I did some benchmarks to evaluate JNI-call-per-operation vs.
> Command-batch-buffer performance for a design where low per-primitive
> overhead is important.
>
> I was totally impressed about the low overhead JNI has in modern
> SUN-JVMs. On my Core2Duo-2ghz it took only 35cycles to call a native
> method with 4 jint parameters and count an int-loop-counter up, 58mio
> times per second. Making the methods synchronized however time went up
> to 100 cycles per call.
>
> Has JNI really become that fast, or is it likely that I have hit a
> microbenchmark trap?
> I thought JDK6 has BiasedLocking (I only tested single threaded), why
> is synchronization so expensive in this case? (my call-graph is
> benchmark-loop -> (synchronized) accessor-method -> native-method).
>
> Thanks, lg Clemens
More information about the discuss
mailing list