JNI-performance - Is it really that fast?

[Martin Buchholz]

BTW,

The implementation of ReentrantReadWriteLock is being changed significantly
by the not-yet-integrated changes for

*Synopsis* Excessive ThreadLocal storage used by ReentrantReadWriteLock
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6625723

which may make your particular workload faster (hopefully!) or slower.

Martin

On Tue, Mar 25, 2008 at 12:57 PM, Clemens Eisserer <linuxhippy at gmail.com>
wrote:

> Hi again,
>
> Thanks a lot for the valueable feedback :)
>
> > Biased locking is enabled 4 seconds after startup.
> Thanks a lot Christian and greetings from Austria!
> With your suggested flag the synchronization-overhead with
> BiasedLocking shrinks to about 10-20% on my Dual-Core machine down
> from a few hundred percent.
> Do you know wether ReentrantLock could also be optimized to use
> BiasedLocking? In my use-case most likely one thread will
> aquire/release the lock again and again, maybe from time to time
> another thread will aquire it, but rather seldom.
>
> > Our per primitive cost is still mostly
> >  consists of jni overhead for small primitives (think
> >  fillRect(1x1)).
> For my fillRect(1x1) test the locking of AWT's ReentrantLock was far
> more expensive than the JNI overhead even with almost no contention.
> That was for a VolatileImage, on a Dual-Core machine, on a single-core
> machine I tested on the hit was much smaller.
>
> >  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. :-)
> Its really impressive, congratulations and thanks to the vm engineers
> who made that possible  :) ;)
>
> Thanks a lot, lg Clemens
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20080325/048baefd/attachment.html>