Due to some technical problems, I haven't been able to send out the fully featured newsletter that I intended. I've had to delay the two new columns on performance tools, though I promise (barring a catastrophe) they will be in the next newsletter. But the small number of articles listed in the "recent articles" section is not because we haven't searched as much as normal. In fact I've looked through more articles this month than any previous month, and there were many interesting articles on other aspects of Java. But only six articles had tips relevant to Java Performance.
Kirk and Javva are still here with their excellent columns. Javva continues his diary, showing you ways to use performance tools that you might never have considered. And Kirk shows you how to use metrics to anticipate how much tuning work you have ahead of you, as well as covering the Java performance discussion groups.
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 http://www.hatena.org/JavaPerformanceTuning/ in a while.
As part of our ongoing commitment to informing our readers about performance tools, JavaPerformanceTuning.com 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.
Java performance tuning related news.
All the following page references have their tips extracted in the tips section.
These are pages which hold information of interest to the Java performance community, but I haven't had time to extract the tips.
As I?m sitting here at my keyboard generating these words, I?m thinking what an interesting month this has been for me. Now, as much as I like cranking out code, sometimes you?ve just got to stop and take a step back. That?s exactly what I did this month. I took a step back to look at how the software was built in my current project. It was an eye opening experience to say the least. After taking a look, I quickly realized that I couldn?t just go to management and say, "the code base is a bit unusual". I had anecdotal evidence to support such a statement but I needed something stronger, something indisputable. For that level of assurance, I turned to software metrics.
There are a number of tools that will perform some obscure calculation such as violations of the law of Demeter. The tool I happened to have at hand was TogetherJ. So, I grabbed the latest version of a project from the source code control system, pointed the TJ at it and fired. After the gears turned a bit and the CPU got fairly hot, TJ presented me with a pretty large matrix filled with acronyms and numbers. What did all of these numbers mean? Were the numbers bad and if so, how bad? Could these numbers validate the anecdotal evidence that I had amassed? To find out, I went out into the open source community and downloaded the source code from a number of projects. Again, I pointed TJ at the source and fired. As before, TJ dutifully generated that extra large matrix full of obscurity. But this time, I was able to take the numbers and create some population statistics. With these statistics in hand, I was now able to evaluate the numbers from the first project.
I must admit that my motivation for running the metrics was quite selfish. I knew that I was going to have to deal with the source code and I wanted to know what I was up against. In this case if was looking for three measures, volume, complexity and couplings. Understanding these numbers provided me with a clear sense of how difficult and time consuming it was going to be to modify the code. Since my goal was to performance tune that piece of the system, these measurements helped me devise a strategy to not only deal with the code base, but to set expectations as to how much could be achieved with the given time budget. After all, a major part of performance is about expectations.
Now lets review the hot topics of the last month.
From the Java Ranch, we have an interesting thread that discusses the question "why does my GUI take up so much memory?" Generally, the responses that one receives from the ranch hands to this type of question are thoughtful and quite helpful. In this instance, the response referenced a paper on the alphaworks website that suggests that one should implement a destroy interface in which one would then null out references to fields in the object. Now, I haven?t actually read the paper so I can?t really comment on that but the rule for Java is that if you release a reference to an object, it is subject to be garbage collected. In addition, any references held by that object will also be subject to GC assuming that they are not reachable from an object that is not subject to GC. This is different from C++ where there is no GC. Consequently, C++ programmers are obliged to release memory using (strangely enough) a destructor. That destructor is responsible for possibly calling the destructor for any objects that it is referencing.
Now the question is, how do you know if another C++ object is holding onto your object? The general answer is, you don?t. That is why people like GC. It handles this for you. Hence, it alleviates most (but not all) of the problems associated with memory management. The point is that if you maintain a reference to an object, it will never be eligible for GC. So, in these systems, the most common symptom that you're not releasing references is that you experience memory bloat. Now, granted the destructor as it?s been applied in the discussion thread may be a nice hack to get around the problem, but it doesn?t solve the problem. For that, I?d recommend a memory profiler such as JProbe or OptimizeIt. With one of these tools, you can find the memory leak and fix it at the source rather than throwing more code at the (already bloated) problem.
Here?s a question that produced a few interesting tidbits of information. Which is faster
if (myarray == Boolean.TRUE)or,
if ( ((Boolean)myarray).booleanValue()).Though the question may seem trivial, what it does reveal is that the first statement should always return false. Why? Because == checks identity. A better check would be to use
The interesting tidbit is that this appears to change in the JDK1.4. In that version of
the JDK, it is recommended that you use
Boolean.valueOf(boolean) as this does not require
that you create many identical objects. Plus, you can get away with using ==, which is a
slighter faster operation. One final note,
new Boolean(true).equals(new Boolean(true))always returns true.
The gaming developers were up to their usual task of trying to push the envelope even further. There was a very interesting discussion between two developers concerning some problem in the AWT that was causing a simple animation to consume 100% of the CPU. HProf was reporting that the code was spending 96% of its time in sun.awt.windows.Wtoolkit.eventLoop on the AWT-Windows thread. After much speculation and banter back and forth, a test was devised in which a JNI function named go() was created. Its function was to call Sleep(INFINITE). The test started three threads, the main, an AWT thread, and one to execute go(). HProf reported that all three threads consumed equal amounts of CPU time. Conclusion, -Xrunhprof cannot report statistics on native code.
Will we see Java running on vector processors? As it turns out, there is a strategy that could see a specialized JIT replace the byte codes in your class file with a vectorized set of instructions. Just don?t expect to see it in the near future. In the same thread, there is a nice explanation of an AOT compiler. For those of us that have not run into this acronym, it?s an ahead of time compiler. From my experience with vector processors, I understand the need for code to behave the same when running in either scalar or vector modes. Java?s exception handling presents a problem for vector processors. The participants felt that an AOT compiler might help solve this problem. This seems like a reasonable conclusion as Cray used this strategy (as a part of a static compiler) to vectorize C, C++, and Fortran code.
The Server Side continues to provide a wealth of J2EE performance tuning information. This is evidenced by a discussion that centered on the question, "should one use CMP 2.0 or BMP with a DAO". Though the group as a whole came down on the side of CMP 2.0, no one could produce any numbers to help answer the original question. As a side conversation, one participant explained why these numbers might not be of any use anyways, as a system will perform differently on different hardware configurations. For example, it is unlikely that your system matches those used for the ECPerf tests. This is pure speculation, but I bet that if a vendor did publish numbers for optimal hardware configuration for their software, that the customers would choose to follow suit.
In a thread that was seeded by the Middleware?s own Floyd Marinescu, participants were asked to make a performance comparison between stateless session beans and servlets. The discussion brought out a number of points and, in the end, exposed a number of myths. One point that many agreed upon is that performance and scalability needed to be looked on as separate concerns. In this light, anyone who was using EJB to improve performance would be disappointed. It is true that every time you separate a tier with a communication layer such as RMI, you take a performance hit, which may not be recoverable. Even so, it was agreed upon that EJB leads to a more scalable design, allows for greater flexibility for the physical topology of the application, and better designs due to a greater separation of concerns.
It?s hard to believe that it?s only been a little more than a month since the ECPerf wars heated up. Since then, we?ve seen the new ECPerf 1.1 specification released. Both IBM and Pramati announced new results. The IBM results demonstrate a near linear scalability as they moved from a seven to nine node cluster. The resulting Bbop/$ figure remained just about the same. Pramati?s submission is follow by a Q&A session with Ramesh Loganathan of Pramati which can been found at http://www.theserverside.com/home/thread.jsp?thread_id=13262. Though Pramati?s results lag behind both BEA and IBM, one must applaud their efforts to do the work and publish the result.
What a headline. Smaller, faster, better, cheaper. No, that wasn't from a satirical version of the six million dollar man (though come to think of it, that's not such a bad idea. Maybe I should put together a proposal for the networks, it would be just as good as a lot of the other drivel I watch on the box). It was from the history of a dot-com millionaire was-a-be ( opposite to a wannabe, "waz-ah-bee", not wasabe as in Japanese green mustard). This guy had already been a paper millionaire for a bit. I was reading the article over at http://www.sdmagazine.com/documents/s=7144/sdmweb0205a/0205r.htm.
The story itself would be amazing if it wasn't almost commonplace in the dot-bomb bubble. But that heading really caught my eye. After all, it is the ultimate goal of the performance tuner. We should make it into a bumper sticker. You know, like the double-entendres in "Accountants do it calculatingly" and "Racing drivers finish quicker".
"Good coders perform faster, better and are cheaper with smaller equipment". Ugh. Not so good huh? How about "Tuners make it smaller, faster, better and cheaper"? Just doesn't have that sound-bite feel to it. Oh well, if you can come up with a good one, tell me and I'll tell the rest of yoooze.
Sounds like a good name for a product. CRMish I think. In fact its another article over at Software Development mag (I don't have anything to do with them, honest guv). http://www.sdmagazine.com/documents/s=7151/sdmcnf0204i/sdmcnf0204i.htm.
This one caught my eye because the design process and the design ended up smaller, faster, better, cheaper. A good read. Sounds like a good seminar.
XP always seemed to me like a developer's dream and a managers nightmare. It's really the way I'd like to develop. You get to do half the work while you chat to a fellow coder and do all the easy bits. There's no boring test cases to do after you've finished coding, because all the test cases are what you've been coding in the first place. And snooty know-it-all designers are reduced to glorified QA guys. Okay, maybe its not quite like that, and I haven't met a snooty designer in a long time, but it sounds like fun.
April 25. Lunch with Parsons. Third time in the last two weeks. Deliberate ploy on my part. I'm trying to get him to recommend another round of tuning on the server. Feed him various BS about new JVM versions, awesome improvements, potential significant speedups, etc. He's really going for it.
April 30. Frezian tells me he is working on getting me to do another round of performance tuning on the server. Confides in me that he has heard about potential significant speedups, and he is now working on convincing Parsons. Bigmouth tells me he overheard Parsons telling Frezian about potential significant speedups ...
May 2. Start setting up customized performance tuning environment. I need this to be mostly standard, but just obscure enough that no-one else is going to be able to use it without detailed instructions from me.
May 7. Do a recursive search on the repository to find all classes authored by Weevil. Then I run some preliminary profiles on the server. Take the top fifty classes in the various profiles, plus all of Weevils classes, and put that in as the filter for all future profiles. Don't you just love these modern profilers, it's a wonder what they can do. Weevil's classes will seem to dominate any profile if you look at lots of classes. Now I'm almost ready to present preliminary findings. Just a little more to do.
May 9. Build a script which adds various information to profile output: time last changed, version, author. Author is the only one I care about, but it would be too obvious without some others. Frezian requires reports for next week.
May 14. Full meeting. SquintFace notices the predominence of Weevils name in the profile outputs, and points it out. Frezian scrutinizes the "author" column. Weevil wants to see the profiler in action. No problem. We break away after AOB and about five, including Frezian, watch as I run through some basic profiling. Inevitably, some of the bigger bottlenecks include Weevil's classes, so I choose one of those to dive into and start analyzing. Couldn't have been better if I had prepared it! He was creating half a dozen redundant objects repeatedly in a loop. Frezian mutters something about possibly needing code reviews for some of the "weaker" developers. Weevil looks like he could start foaming at the mouth any time soon.
(Note: all names have been changed to protect the guilty).
Javva The Hutt.
Sun community chat on High Performance GUIs with the JFC/Swing, with Steve Wilson, Scott Violet, and Chet Haase (Page last updated April 2002, Added 2002-05-19, Author Edward Ort). Tips:
J2ME game building (Page last updated April 2002, Added 2002-05-19, Author Dale Crowley). Tips:
Optimizing Searches via Rare Events (Page last updated April 2002, Added 2002-05-19, Authors ANDREA MONTANARI & RICCARDO ZECCHINA). Tips:
File Channels, StackTraceElements, (Page last updated May 2002, Added 2002-05-19, Author Glen McCluskey). Tips: