Here I am at TS-3268, "Java Technology Performance Myths Exposed," with Cliff Click, of Azul Systems. Azul, founded in 2001, advertises itself as pioneering "the industry's first network attached processing solution, designed to unbound compute resources for virtual machine based applications. Without any application level modifications, binary compatibility requirements or operating system dependencies, this fundamentally new approach eliminates the need to capacity plan at the application level and dramatically lowers the cost and complexity associated with the traditional delivery of computing resources."
Click enumerated six performance myths. What follows are the basics.
Myth One: The notion that you can add the "final" key word and your code will run faster. The assumption is that by adding the "final" key word I allow the JVM to inline and do the right thing. Not true. "Final" won't make your code run faster.
Myth Two: Try/catch blocks are free or they're very expensive. Google gives both bits of advice - that it was free or kills performance. Both are wrong. It is both very cheap and very expensive - depending. Advice: Don't put try/catches in very tight array loops. Otherwise it's more or less free.
Myth Three: Use RTTI - Run-Time Type Info. Compared RTTI versus instance-of if-tree versus virtual call. RTTI makes for really ugly code - it is fast though, so only use it if you're desperate for that last bit of performance.
Myth Four: Synchronization is very expensive. The truth is synchronization is not free, but it's no longer so expensive. It's gotten a lot cheaper over the years.
Myth Five: Object pooling works. The idea is that we can reuse objects by pooling them on and off free lists instead of using new and letting the garbage collector pick them up. Once you have more than one thread going off the pool, you need a synchronized free list, which has costs. If the list gets hot and contended, you can get scaling bugs. It gets complicated too fast and is not worth it for small to even moderate sized objects. Use it only for large objects.
Myth Six: The cost of the revisions to Java Platform Standard Edition 5.0 are substantial. Not true. Enums, autoboxing and varargs are mostly free.
Cliff wrapped up his session with a few final observations:
GC is getting cheaper and pretty efficient, and less intrusive. There are still scaling problems with large heaps.
Object pooling will remain viable for largest objects with high costs. Small objects will get even cheaper.
Click closed with one piece of advice: "If you take away only one thing from his talk, it would be that modern JVMs favor common usage patterns and clean code."