Unlocking Java performance myths |
 |
By Jack Vaughan, Managing Editor
23 Apr 2008 | SearchSoftwareQuality.com |
|
|
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 engineer, Sun 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."
|
|
|
|
