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@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