Java Performance Tuning

Java(TM) - see bottom of page

|home |services |training |newsletter |tuning tips |tool reports |articles |resources |about us |site map |contact us |
Tools: | GC log analysers| Multi-tenancy tools| Books| SizeOf| Thread analysers| Heap dump analysers|

Our valued sponsors who help make this site possible
JProfiler: Get rid of your performance problems and memory leaks! 

Training online: Concurrency, Threading, GC, Advanced Java and more ... 

Newsletter no. 20, July 25th, 2002

Get rid of your performance problems and memory leaks!

Modern Garbage Collection Tuning
Shows tuning flow chart for GC tuning

Java Performance Training Courses
COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs

Java Performance Tuning, 2nd ed
The classic and most comprehensive book on tuning Java

Java Performance Tuning Newsletter
Your source of Java performance news. Subscribe now!
Enter email:

Training online
Threading Essentials course

Get rid of your performance problems and memory leaks!

This month we have everything. Our biggest newsletter yet. Kirk's roundup, Javva The Hutt's diary, my new tips, all the news and interesting articles from the last month, new category pages in the tips section of the website and two performance tool reports. And I've even started making inroads into the backlog! Ten years ago this would have been a corporate newsletter costing about $1500 for a year's subscription. Now my sponsors, contributors and myself are subsidizing the costs, so don't forget to visit's sponsors if you are interested in their messages.

A note from this newsletter's sponsor

Get a free download of GemStone Facets 2.0 and see how this
patented technology supports JCA 1.0 to seamlessly integrate
with J2EE application servers to enhance performance.

Our tool reports this month cover Hendrik Schreiber's GCViewer tool for viewing garbage collection statistics and, Velocitop's Catapult Java-to-Oracle performance tuner. All our tool reports, past and present, are available from the tool reports page.

The new articles listed this month are as usual wide ranging, covering J2ME, J2SE, J2EE, JDK 1.4, web servers, application servers, database communications, graphics, servlets, JSPs and patterns. You could be mean and not tell your colleagues about, since we do give you an edge. Or you can be generous and let them know about the best newsletter in the business. In a representative poll 50% of our contributors said you should spread the word (that was Kirk), and 50% said keep it to yourself 'cause it's a dog-eat-dog world and information is power (that was Javva).

Don't miss Kirk's roundup of the Java performance discussion groups, talking about -O, fast collection handling, nanosecond timing, J2EE transactions, and much more. And Javva The Hutt keeps up with the latest installment of his diary.

If you feel this newsletter could be useful to a friend, why not send them the URL. Note also that Yukio Andoh's Japanese translation will hopefully be available at in a while.

A note from this newsletter's sponsor

Precise Software revolutionizes J2EE Application Performance
Management with automatic problem detection & correction. Read
our white paper on how to instantly isolate J2EE bottlenecks.

Reminder to vendors and creators of performance tools

As part of our ongoing commitment to informing our readers about performance tools, presents one commercial tool and one non-commercial tool each month. If you are a vendor or creator of such a tool, and would like to have your tool presented, please contact me from this page. But do please note that we work on a first-completed, first-published basis. There is already a queue of vendors and freeware authors creating submissions for this column, so if you want your tool to be presented in the near future, contact us sooner rather than later.

Tool reports


Java performance tuning related news.

A note from this newsletter's sponsor

We have one remaining sponsorship slot for
If you want your message to be seen by thousands of people
interested in Java Performance, please visit our sponsorship page


Recent Articles

All the following page references have their tips extracted in the new tips section.

Older or backlogged articles

All the following page references have their tips extracted in the new tips section.

Jack Shirazi

Kirk's roundup

Has anyone noticed that the -O no longer does anything? Where has the -O gone? Why has it been neutered and finally, will we miss it? It used to be that static analysis was the mainstay of performance tuning. During my bit-jockeying days on the Cray Research line of computers, I relied at lot on the ability of the Cray C optimizing compiler to produce the best machine code possible. This was not an easy task. For one thing, there was the requirement that code that ran in vector mode must produce the same results as if it were run in scalar mode. Consequently, some very mundane techniques commonly used in C would force the optimizing compiler to generate scalar code instead of vector code. For those of you who may be familiar with Cray supercomputers, you know that most desktops will out-perform an XMP when the XMP is running in scalar mode. The real power was in its vector processing features. You could force the compiler to optimize the code using a pragma statement, but the consequences were that your results may not be correct.

The real problem was that the compiler had no idea of how you were going to use a particular function. With pointers in C, there was no guarantee that you wouldn?t over-write memory before accessing it in a tight loop. Of course, this determination could be made at runtime but, since this would come at what was determined to be an unacceptable performance penalty, only static analysis was ever employed. Consequently, performance tuning involved a lot of profiling and tweaking of code to ensure that the resulting executable was optimal.

Now, along comes Java and, like the Cray C compiler, it only performed static analysis of the code. This offers very little gain for all the effort. Granted JIT?s improved the picture by caching the machine instructions for commonly used code. But, the addition of HotSpot has truly added value with its ability to perform dynamic analysis of an application's code base. In most cases, the cost of performing the analysis is paid back in spades as most Java applications now run much faster. This result called into question the value of the -O parameter given that Java is supposed to be platform independent. As I have described earlier, in order to get C code to vectorize, you needed to change your style of coding. Consequently, how the code performed became dependent on the platform. This suggests that static analysis produces byte code that performs differently on different platforms [and I can confirm that, I've had exactly that experience for a small subset of optimization techniques - Jack].

The optimizations derived through the dynamic analysis of running code are far superior to those that could be produced with the -O option. This has reduced the need to statically optimize the byte code. With each successive release of HotSpot, the dynamic optimizations are only improving. So, will you miss the -O option? Given all of the other bottlenecks that exist in the JVM, probably not. Will the -O return? It?s hard to say but it seems clear that the separation of optimization from compilation has improved the performance characteristics of most applications. This leads one to believe that the best scenario is for the compiler to produce solid byte code and for HotSpot to perform the platform specific optimizations.

Now lets move onto this month?s summary of the discussion groups.

The JavaRanch

From the Saloon down on the JavaRanch we have the usual array of performance related questions that lead in some very interesting directions. The first question I?m going to deal with is which piece of code is faster. The only answer that was provided was this excellent advice.

Rules of optimization

  1. Don?t
  2. Don?t... yet (for experts)
  3. When you really need to, profile first as the bottleneck will not always be where you think it is.

The last bit of advice was this useful URL, If you?ve not been to a wiki web before, then you?re in for a special treat. With the right query, the wiki web will auto generate html pages with the information you?re looking for. The best part is that if you?ve anything to add, there are facilities for that also.

Next on the list is the age-old question of is C++ faster than Java. After the usual barrage of claims, there suddenly appeared a gem. A greenhorn replied that he had implemented a matlab like engine in Java. The development took two months. His employers then had him rewrite the package in C++. The Java code took up 1/3 of the disk space and ran about 20% slower. The interesting bit is that the conversion took six months! As a colleague of mine used to say, "I?d rather waste the computers time than mine".

Are two collections better than one? Well, that all depends. If you?re trying to remove duplicates from an ArrayList like one greenhorn was attempting, then the answer is yes. That is of course if maintaining the order of elements is important. Here?s a code fragment.

ArrayList a = new ArrayList(a_master);
long cur = System.currentTimeMillis();
Set set = new HashSet();
List newList = new ArrayList();
for (Iterator iter = a.iterator(); iter.hasNext(); ) {
    Object element =;
    if (set.add(element))

Now, if maintaining order is not important, and then once you?re dealing with more than 100,000 elements, it?s best to switch techniques to:

ArrayList a = new ArrayList(a_master);
long cur = System.currentTimeMillis();
HashSet h = new HashSet(a);

This really shows the usefulness of a properly constructed micro benchmark.

And finally, the debate over which is faster, dot net or Java, has spilled into the Performance discussion forum. It seems early for dot net to come up with a fair answer to this question. The original poster had his ideas but I have questions about the validity of his micro benchmark. It will become more interesting once some real comparisons come into play.

Ever probing the boundaries of performance, a gamer at posted a question on how to profile Java3D. Apparently, there is currently no good means to have the Java3D package reveal it?s performance secrets. Since gamers live and die by being able to measure just about every aspect of a gaming experience, this will certainly need to change.

The next question of interest was how to measure down to the nanosecond in Java. Out of the discussion came a number of salient points. First, the current accuracy of timings in Java is 10ms. This does not vary between System.currentTimeMillis() and the TimeStamp class. Although portability was posted as the reason why, the retort was that one could provide the highest possible resolution in a portable manner. Jeff Sutherland (Sun performance expert) remarked that Sun was thinking of adding this capability though when was not stated. The last point was a link given to an article that discusses hi-resolution timers. Just click here

To my surprise, logging is an issue for gamers as well. To this end, there was an interesting discussion on what was the best means to log. There was a vote for the new 1.4 logging package as well as Log4J. There was also another interesting link to zero cost logging. You can find this article at

The Server Side

Last but certainly not least is The first post I?ll discuss here is one concerning a 5x slowdown of an application running in WAS 3.5.1 when the transactions were changed from TX_REQUIRED to TX_SUPPORTS. One possible explanation is that TX_SUPPORTS causes WAS to call ejbLoad() and ejbStore() for every call to a particular bean. With the TX_REQUIRED option, if no changes are made to the bean, these calls can be avoided. Of course, this is an implementation specific detail.

A few weeks ago, I had the pleasure of watching Martin Fowler deliver a talk centered on the material that can be found on his website and will be appearing in his next book. It was, of course, patterns. During the course of the talk, the question of pattern abuse came up. Martin?s answer to that question was education. You may be wondering how this relevant to the server side discussion groups. Well, a post asked the question of how a particular architecture would perform. One of the questions posed was: "Is performance worse if you use design patterns"? The responses played true to Martin's comment as they educated the poster on the judicious use of patterns. Amongst the responses was one that suggested that the number of layers in an application was a question of good design, not performance. Yet another suggests that the poster resist the temptation to use every design pattern possible. I would add that one should only build what the requirements call for. I?ve witnessed a few projects that delivered late by not following that edict.

If you?re willing to anti up the fee (of $1100USD), there is an interesting report published at on J2EE server performance. A more through check of the site revealed some performance tidbits that one could readily view. You may want to checkout the new ECPerf results published by BEA. They now have the highest BBOP (37381) rating but it comes at a price of $38/BBOP. That price is without clustering, a configuration that IBM has always contested as being unreasonable for a production environment. [More recent results are now available, see this month's news section].

On a final note, I was in a meeting with a vendor this week. What was interesting was that they claimed their Java component ran faster on Windows NT 4.0 using IBM?s VM than it did on any other VM/platform combination (including RedHat Linux 7.1). Since this runs counter to the benchmarks that I?ve seen, I questioned them on it but they stuck to their story. It seems the truth will be told in an upcoming benchmark.

Kirk Pepperdine.

Javva The Hutt

Did you read Norman Richards article, "The smallest Hello World" in the latest JavaDevelopersJournal? What a hoot. Minimizing bytecode size is an aspect of tuning that I rarely need to do. Actually, I've never needed to do it. But then I haven't done any embedded work. I noticed that the techniques Mr. Richards uses are generally applicable if you are in the group of developers that do need to squeeze your bytecodes down to an absolute minimum. I think Jack is extracting the tips over in his latest tips section.

But the whole issue brought up a question for me. This site is called because it is mostly about improving the performance of your app. What do you call tuning bytecode size? Java Size Tuning? Java Classfile Shrinking Tuning? It sounds awful.

Then I thought of another question. How would you manage to get the fastest Hello World? Well, of course, it depends on what you are measuring. Include the JVM startup time? On which machine, with what resources? I remember Jack's book had a section on startup time, so I had a look. And I realized that the fastest Hello World would involve almost every part of a Java system except for tuning the class itself. Making the "fastest Hello World" is almost exactly the opposite tuning problem to making the "smallest Hello World".

Efficiently getting to sleep

Ever had nights when you just couldn't get to sleep? Too many thoughts racing through your mind. Well go on down/up/across to your computer, fire up and do some work. But first read the following paragraph (from this article "Where's Jini?")

Romano told me his company sees the software world as being in a protocol-intensive period now, citing XML, SOAP, and UDDI as examples; but they see the next cycle as being "protocol-agnostic," offering an opportunity for Jini to move into session and directory spaces now held by the XML-related protocols.

Is it just me, or did your eyes also glaze over before you reached the end of the paragraph. It works every time for me. It's not just the juxtaposition of all those boring acronyms, the paragraph is actually trying to get me excited about the propect of using Jini as a directory service. Zzzzzzzzzzzz.

Diary of a Hutt

June 19. Too clever for my own good. I was only bringing up the idea with Frezian to see what kind of a response it would get. But no, he can't just give me his opinion. Has to drag HasntGotAClue into it. Naturally HasntGotAClue is not going to take it lying down. QA is his domain, and the last thing he's gonna do is sit still while some nobody makes a move. So now they're seriously discussing whether performance testing comes under the remit of development or QA.

June 20. Bigmouth filled me in. HasntGotAClue has apparently been looking for any excuse to grow his department. Stupid me gave him the perfect wedge to start - with me. That's all I need. Well I've learned that HasntGotAClue has got a clue when it comes to office politics.

June 21. Ugh. Could it get any worse? Now Bigmouth tells me that Frezian sees dumping me and Boris as an excuse to expand his development team and improve his stats. Apparently making the applications run faster doesn't show up in his management reports as LOCs or bug fixes, so in management speak we're just a waste of resources.

June 26. I've been fighting a desperate rearguard action. Parsons was dead impressed with the performance improvement of the server, and even brought round a couple of the BIG D's so that I could show the "before" and "after" response times. Parsons was taking all the credit, and I was using that to try to impress on him how effective the current arrangement was. But Bigmouth told me that I had zilch effect. Frezian and HasntGotAClue are in agreement, and Parsons doesn't give, since I stay under him anyway. In a sense I would be better off under HasntGotAClue because he would be able to showcase my work more effectively than Frezian. BUT I'M NOT QA. Not to mention how pleased I was to see Weevil moved to a different department. Even if his cubicle is still about the same distance as it was, at least it's in the other direction.

July 9. Well it's a done deal. As of the end of the quarter, performance becomes a subgroup of QA. I don't actually physically move, though Boris got shunted inwards because Shifty wanted the window seat. It couldn't get any worse than this.

July 17. It just got worse. HasntGotAClue accepted my argument that performance shouldn't be fully integrated into QA, and should remain a separate subgroup reporting to him. I thought I was on a roll. Then he said I'd have an overseer from QA so that we'd be in-phase with QA, he didn't want any communications breakdowns. And apparently the ideal candidate was Weevil, since he was aware of my work from his previous stint in development. Aaaaagggggghhhhhhh!!!!!!!

(Note: all names have been changed to protect the guilty).


Javva The Hutt.

Clustering with JBoss (Page last updated July 2002, Added 2002-07-24, Authors Bill Burke, Sacha Labourey). Tips:
MIDP memory tuning (Page last updated June 2002, Added 2002-07-24, Author Jonathan Knudsen). Tips:{11E331A5-5A08-4FFD-B018-2A7E24D0359B}
Application performance tuning (Page last updated July 2002, Added 2002-07-24, Author Baya Pavliashvili and Kevin Kline). Tips:
HTTP sessions vs. stateful EJB (Page last updated July 2002, Added 2002-07-24, Author Peter Zadrozny). Tips:
Precompiling JSPs (Page last updated July 2002, Added 2002-07-24, Author Steve Mueller, Scot Weber). Tips:
High performance inserts with DB2 and JDBC (Page last updated April 2002, Added 2002-07-24, Author Krishnakumar Pooloth). Tips:
Optimizing padded string display (Page last updated June 2002, Added 2002-07-24, Author Gervase Gallant). Tips:
High load web servlets (Page last updated July 2002, Added 2002-07-24, Author Pier Fumagalli). Tips:,,10493_1145241,00.html
Website usability metrics (Page last updated May 2002, Added 2002-07-24, Author Sharon Gaudin). Tips:,,11952_1370691,00.html
Common issues affecting Web performance (Page last updated June 2002, Added 2002-07-24, Author Drew Robb). Tips:
LinkedHashMap and RandomAccess (Page last updated July 2002, Added 2002-07-24, Author Glen McCluskey). Tips:
Emulating another system (a ZX Spectrum) (Page last updated July 2002, Added 2002-07-24, Author Razvan Surdulescu). Tips:
The smallest "Hello World" (Page last updated July 2002, Added 2002-07-24, Author Norman Richards). Tips:
Speeding web page downloads using compression (Page last updated July 2002, Added 2002-07-24, Author Steven Chau, Publication Tips:
The Verified Service Locator pattern (Page last updated July 2002, Added 2002-07-24, Author Paulo Caroli, Publication JavaWorld). Tips:
Runtime.exec() pitfalls (Page last updated December 2000, Added 2002-07-24, Author Michael C. Daconta). Tips:
Improving J2EE performance (Page last updated May 2002, Added 2002-07-24, Author Scott Marlow). Tips:
Scalable recoverable applications (Page last updated May 2002, Added 2002-07-24, Author Billy Newport). Tips:
Sun Community chat on Java BluePrints (Page last updated May 2002, Added 2002-07-24, Author Edward Ort, Publication Sun Developer). Tips:

Jack Shirazi

Last Updated: 2021-05-25
Copyright © 2000-2021 All Rights Reserved.
All trademarks and registered trademarks appearing on are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
RSS Feed:
Trouble with this page? Please contact us