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