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 <[EMAIL PROTECTED]> 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 >
