Exposing Java Technology Performance Myths
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
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
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."