While investigating rendering performance for the X11 pipeline, we have determined
that a significant bottleneck is our use of the "AWT lock" to serialize access to
Xlib, Motif, and other native libraries. The problem is that the AWT lock is almost
always promoted to a very expensive, heavyweight monitor because a) there is often
contention for the lock and b) we acquire the lock by a combination of the JNI and
Unsafe monitorEnter() entrypoints, both of which cause the lock to be "inflated". An
"inflated" Java object monitor has been shown to be many times slower than a
non-inflated monitor.

This was first reported in 4740695, and a bug was filed
(4922864) to use pthread mutex instead. However, this bug was quickly closed because
XAWT code almost always acquires the lock from the Java side using either the
synchronized keyword or the Unsafe entrypoints, so using pthread mutexes to lock
would require frequent JNI downcalls, which would be even worse for performance.

In JDK 5, the java.util.concurrent.locks.ReentrantLock class was introduced offering
a lightweight locking solution that performs very well under contention, especially
when compared to Java object monitors. We used ReentrantLock in the single-threaded
OGL pipeline rearchitecture in Mustang with very positive results, which got us
thinking that maybe ReentrantLock would be a good replacement for the AWT lock.