Charles Lamb's Blog

[This is a repost of the 10/25/05 Sleepycat blog entry.]

Java 5 has a new lock substrate embodied in the java.util.concurrent.locks
package. These classes are similar to the internal latching mechanisms
that we use in Berkeley DB Java Edition (JE) so it seemed like a
natural choice to make use of this new library in the hopes that they
would provide better performance for JE. After all, the Java 5 lock API
is similar to the com.sleepycat.je.latch
API. In JE, a latch is a short-lived, non-persistent lock on a data
structure (e.g. an internal tree node) that helps JE maintain
consistency. In fact, latches are very similar to synchronized blocks (we opt for synchronized whenever possible), but in some cases, the lexically scoped nature of synchronized is
not suitable. For instance, a technique that JE uses to descend the
B+tree is "latch coupling" (latch A; latch B; release A; latch C;
release B; ...) and this can not be implemented easily with a lexically
scoped construct since the latch acquisitions and releases are
intertwined.

Internally, the JE latch classes use a synchronized block during both the "acquire" and "release" calls. So a JE latch costs at least two synchronized calls, which even though relatively inexpensive, still add up.

Initial
tests of the new Java 5 locks showed that significant performance
improvements might be realized. The only possible downside was that
we'd have to change our latch API to be an interface so that we could
"switch hit" between our latch code or the Java 5 locks, depending on
whether JE was in a Java 5 or 1.4 JVM environment. Once the integration
of the Java 5 locks into JE was completed, we ran our performance
regression tests (a series of "micro benchmarks" that each focus on a
specific JE function) to see just how much difference the new locks
made.

The results were gratifying. For single threaded tests,
any degredation due to calling through an interface (where we hadn't
called through one before) were negligible. For multi-threaded tests,
the more threads in the test, the better the results. Some tests showed
10% improvement, and one customer's write benchmark was even better
than that.

Traditionally, we have seen much better performance
using the Java 5 JVM (especially the "server" JVM), and this adds still
another improvement to JE performance under the "Tiger" JVM.

The Java 5 latch functionality will be available in a future release of JE after it undergoes more testing.