Java 6: What Makes It Faster? A Microbenchmark

In Java 6: What Makes It Faster? we worked through the theory. Now it’s time to see what difference synchronization optimizations make in practice.

Abstract

The benchmark was designed to measure the effect of a new JVM optimization called lock elision, which removes unnecessary synchronization locks. For comparison, I ran the same benchmark on Java 5, including a run with biased locking enabled to reduce synchronization overhead.

Benchmark

Here is the benchmark with synchronization on. For the unsynchronized tests, I used the same version with the synchronized block commented out.

public class TestSynOptimizations {

 public static void main(final String args[]) {

 for (int i = 0; i < 10; i++) {

 long startTime = System.nanoTime();

 for (int j = 0; j < 30000; j++) {

 compute();

 }

 long delta = System.nanoTime() - startTime;

 System.out.println("Total time [ns]:" + delta);

 }

 }



 public static void compute() {

 Object lock = new Object();

 int sum = 0;

 for (int j = 0; j < 5; j++) {

 synchronized (lock) {

 sum = sum + 1;

 }

 }

 }

}

The compute method is designed so HotSpot can eliminate the lock. That should remove the performance difference between the synchronized and unsynchronized versions.

Test environment

• Hardware: Dell D610 laptop
• CPU Intel Pentium M 760 (2.00Ghz w/ 533Mhz FSB)
• RAM 2048 MB (dual channel)
• OS Microsoft Windows XP Professional SP 2

I ran the tests with Java 1.6.0-b105 and 1.5.0_10-b03 in HotSpot server mode. The reserved heap was set in the range of 256 MB to 128 MB to eliminate the effect of garbage collection. I used the corresponding compiler for each Java version. The benchmark ran with the following JVM versions and configurations. Sync and nosync indicate whether the benchmark code used synchronization.

• Java 6.0, sync
• Java 6.0, sync,-XX:+DoEscapeAnalysis
• Java 1.5.0_10, sync, -XX:+UseBiasedLocking
• Java 1.5.0_10, sync
• Java 6.0, nosync
• Java 1.5.0_10,nosync

A note on the JVM configuration

• -XX:+DoEscapeAnalysis enables the analysis needed for lock elision as of Java 6. It’s off by default.
• -XX:+UseBiasedLocking turns on biased locking, which is also available in Java 5 as of update 06.

Measured values

The following table shows the results of each measurement iteration. An iteration means one pass through the body of the outermost loop in main. The last two rows show averages. The final row excludes the first two iterations because HotSpot’s work skews them.

Image could not be loaded. Archive image in Java 6: What Makes It Faster? A Microbenchmark, figure 1

↗ Medium

Full-size image (about 37 KB).

Results chart

Image could not be loaded. Archive image in Java 6: What Makes It Faster? A Microbenchmark, figure 2

↗ Medium

Full-size image (about 22 KB).

HotSpot optimization during the first two iterations greatly skews the first chart, so chart two gives a much more accurate picture. The results clearly show that eliding unnecessary locks works in Java 6. The synchronized version with escape analysis enabled runs at the same speed as the unsynchronized version. Biased locking in Java 5 is interesting too. It brings performance up to that of the synchronized Java 6 version. This suggests that biased locking is on by default in Java 6.

Unfortunately, I don’t have specific numbers on the effects of these optimizations in real applications. I say “real” deliberately, because this microbenchmark is mainly a way to test theoretical assumptions. Even so, on these results I’d venture that Java 6 gives most applications a substantial performance boost essentially for free.

The results table and charts are also available in a PDF document, which is a better medium for presenting measured data.

Update: In Lies, Bigger Lies and Microbenchmarks :), Jarda Kameník sets the record straight about measuring the unsynchronized version.