News Stay informed about the latest enterprise technology news and product updates.

Unlocking Java performance myths

Best methods of object allocation, garbage collection and synchronization change as the Java Virtual Machine evolves, and this means performance tuning truisms change as well. Improvements may even position the Java language as a speedier alternative to C. At TheServerSide Java Symposium last month, Java performance specialist Brian Goetz discussed the issues.

Where the Java Virtual Machine (JVM) is concerned, development teams need to revisit performance practices regularly, according to performance specialist Brian Goetz. Together with Cliff Click, chief JVM architect at Azul Systems, Goetz led a session covering ''Java Performance Myths'' last month at TheServerSide Java Symposium in Las Vegas.

There certainly is room for tremendous improvement
in VM performance, but in terms of the benchmark we are always compared to -- C performance -- Java has caught up and in some ways has pulled ahead.

Brian Goetz
Senior staff engineerSun Microsystems

The discussion emphasized that performance truths gained during the early days of Java are not all still true. In Java development, the JVM is constantly undergoing development, noted Goetz, and best practices for performance can change as a result.

One JVM performance myth is that object allocation is slow. Like most myths, "this had basis in fact a long time ago," said Goetz, senior staff engineer at Sun Microsystems and author of Java Concurrency in Practice (Addison-Wesley, 2006).

"In JDK 1.0, object allocation was very slow, so was garbage collection," he said. As a result, developers pursued object pooling, which could lead to performance problems such as memory leaks. But with new revisions to the JVM, garbage collection got better. System architects can gain performance advantages by exploiting this.

Synchronization and benchmarks
Another aspect of Java that has changed for the better is synchronization, according to Goetz and Click. In the early going, every lock acquisition/release required OS calls. This caused developers to avoid synchronizing. Now, better locking algorithms, adaptive locking mechanisms and other key improvements have altered the mix. And, according to Goetz, JVMs are "'smart" enough that unshared synchronized collections in most cases run as fast as unsynchronized ones.

Goetz and Click advise teams to look at performance tuning as a moving target and to be prepared to rethink accepted notions. Benchmarks particularly bear watching. Developers rely on them, yet they may have flaws, and changes in the underlying technologies can affect results.

In technology, it seems, what's true today may be false tomorrow. According to Goetz, even the long-accepted truism that C++ is faster than Java may come in for review as the JVM continues to evolve.

Goetz: Java performance best practices evolving
Listen as Java performance specialist Brian Goetz discusses improvements to the Java virtual machine. As Java performance advances, developers should be aware how these changes affect Java best practices.

>> Listen to the podcast

VM evolution
Goetz said the virtual machine is meant to handle performance issues in order to let programmers focus on code and correctness.

"For many years, people complained Java is slower than C. The promise of the managed-code approach has always been [based on] the programmer ceding control to the platform, and the platform [being] able to make better performance decisions.

"In the very early days, that wasn't actually delivered on. That was just a promise that was unfulfilled. Now we have come to the point where this promise really is fulfilled," he said.

"The performance promise we have been making all along has at least started to arrive," Goetz continued. "There certainly is room for tremendous improvement in VM performance, but in terms of the benchmark we are always compared to -- C performance -- Java has caught up and in some ways has pulled ahead."

Dig Deeper on Topics Archive

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

In my experience, Java is rather performant in the scenarios laid out in the article. While I have not done any benchmarking, it would not surprise me if Java was as fast as C/C++ in many cases. However, program startup requires loading up the JVM which means that users may perceive slowdown in spite of the fact that it is over all quick. While I admit there are few GUI applications I have seen in Java of late, I have also found that Java seemed slow regarding UI when I used them.  Since Java UI has a very distinct look, those experiences stick in my mind, which I wonder if that perception is why Java continues to be plagued with the idea that it is slow.
Thanks JCD, that's great feedback. This article was written a few years ago and I think Java performance has continued to improve, as Goetz predicted. But the performance myths obviously haven't been put to rest just yet.
For most tasks, I'm convinced the speed improvements between newer versions of C++, Java, C#, whatever are actually less important, than in how the style of the language makes it easier and quicker to build systems.