Re: Why is ReentrantLock faster than synchronized ?

> a recent article by Brian Goetz made me wonder about this again. Brian
> demonstrates, how ReentrantLock has a performance and scalability
> advantage over synchronized.
>
> Did anyone investigate why that would be the case? Is it due to the fact
> that the VM has lock-enable *any* java.lang.Object through things like
> header displacement, lock inflation/deflation? Or has GC an advantage
> over manual management of lock records?


There's some friendly competition among those doing Java-level sync
vs VM-level sync. The underlying algorithms are increasingly
pretty similar. So you should expect relative performance differences
in typical server applications to fluctuate across releases. The main
goal of ReentrantLock is NOT to uniformly replace builtin sync, but to
offer greater flexibility and capabilities when you need them, and to
maintain good performance in those kinds of applications.

The people doing VM-level sync also have to concentrate on issues that
we don't with ReentrantLock, like the need to use only a few bits of
object header space to avoid bloat in objects that are never
locked. This impacts impmentation details allowing ReentrantLock to
sometimes require a few cycles less overhead.

Also VM-levl support must deal with the fact that many
programs/classes do a lot of sync that is entirely useless because it
can never be contended. (We assume people hardly ever do this with
ReentrantLock so don't do anything special about it.) Techniques to
greatly cheapen this case are probably coming soon in hotspot and
other VMs. (This case is already pretty cheap on uniprocessors, but
not multiprocessors.)

There are currently still a few things that can be done at JVM level
that we can't do at Java level. For example, adapting spinning to vary
with load averages. We're working on leveling the playing field here
though :-)

-Doug