JNI-performance - Is it really that fast?
martinrb at google.com
Tue Mar 25 14:08:37 PDT 2008
The implementation of ReentrantReadWriteLock is being changed significantly
by the not-yet-integrated changes for
*Synopsis* Excessive ThreadLocal storage used by ReentrantReadWriteLock
which may make your particular workload faster (hopefully!) or slower.
On Tue, Mar 25, 2008 at 12:57 PM, Clemens Eisserer <linuxhippy at gmail.com>
> 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...
More information about the core-libs-dev