[an error occurred while processing this directive]
Back to newsletter 016 contents | All Javva's articles
How did I get here? Ah, one of the great existentialist questions. In my case, I can answer it. Our Great Leader (OGL) asked me if I'd like to write a column for his website newsletter. "Something related to Java performance" he said. "How about if it's related to Java, and I write it real fast?" said I. Ever noticed how email doesn't let you see someone's reaction?
OGLs website provides a huge list of tips to make your Java app perform faster. I could have used these tips years ago to avoid severe embarrassment. I was once looking for the bottleneck in a bank middleware app. The head of the project swung by one night when there was just me and another nerd playing with the server. "How is it going?" he asked. After the usual round of blah blah blah, we got down to what he really wanted to know: where was the problem?
"Is it I/O?" came the first question. "No" said I, having definitely identified that the disks were under-utilized and that there was no problem with paging. "Memory then?" he asked. "No, we've still got lots of spare RAM" I answered. "Ah, so it's swamping the CPU." he said.
Now, I was working for a middleware app vendor. If it was bottlenecking on the CPU, it was going to have to be an application problem or else my real boss was going to be real unhappy. But I hadn't been able to find an application bottleneck yet. Heck, I hadn't found any bottleneck yet. This was quite a few years ago, Java was relatively new and the state of profiling tools was quite basic. And the state of my profiling knowledge was also quite basic. So I stupidly replied "no, its not the CPU, I haven't found any bottlenecks yet".
In case you haven't thought it through, an application which has no I/O bottleneck, no memory bottleneck and no CPU bottleneck takes no measurable time to run. Or at least it's fast enough that it doesn't need someone sitting at a workstation for days trying to find out why it isn't fast enough. I kept my job, but I never managed to lose my ability to make stupid statements.
Anyway, I did some hard thinking, and fiddled a bit and finally worked out that garbage collection (GC) was taking ugly amounts of time. It hadn't shown up in the method profiling, or at least I hadn't recognized it then if it had. Nowadays, the first thing I look at is GC. Hopefully, OGLs website will help me avoid looking stupid in the future sometime, when some obscure new bit of Java isn't performing and I don't know why.
Speaking of obscure Java, I found this tip in OGLs tips page:
"The -Xoptimize flag seems to improve performance on those 1.2.x JVMs that support it."
What the? Where did this -Xoptimize option come from? It sounds like it could be pretty useful. So I tried to track it down. Info was real sparse. The originating doc said this:
"Note that the -server option in Java 2 SDK 1.3.0 is equivalent to the -Xoptimize option in Java 2 SDK 1.2.2. The -server option is recommended for all server-side applications, and is especially useful in optimizing CPU-intensive code."
But my 1.3 and 1.4 JVMs all recognize the option. Is it just a psedonym for -server? The Sunsite 1.2 release notes say
"The virtual machine (VM) in version 1.2.2_11 (and prior versions) of the Java 2 SDK, Standard Edition, recognizes the experimental -Xoptimize command-line option. Future update versions of the Java 2 SDK 1.2.2 will not have the -Xoptimize option, and the use of this flag is strongly discouraged. Performance results using this flag have been very mixed, and there have been failures associated with its use."
And finally, the sun answer book says
"(SPARC only) Experimental only. Spend more time optimizing methods in the JIT. This option will most likely benefit long-running CPU-bound applications and might result in increased performance of your application."
Seems like it is the -server option, only not stable in 1.2. Well at least now I won't look stupid if someone asks me about the -Xoptimize option. [You might not sound stupid, but I'm not sure about the look - ed.]
I was flicking through some of the Sun guys home pages. Bill Joy's listed Peter Deutsch's "The Eight Fallacies of Distributed Computing" which I brought to the attention of OGL. I think he's putting it into his tips list for this month. So I was thinking, have we got great fallacies of Java? How about these for starters
Send me your suggestions. I'll compile them and report back sometime in the future. Oh, and try to keep them clean. I know some of you have furtive imaginations.
Javva The Hutt.
Back to newsletter 016 contents