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|

Our valued sponsors who help make this site possible
AppDynamics: Get complete browser to backend visibility. Monitor Now! 

New Relic: Try free w/ production profiling and get a free shirt! 

ManageEngine's Site24x7: End-to-End analysis on Java EE web transactions. Sign up for FREE! 

Newsletter no. 34, September 30, 2003

Get rid of your performance problems and memory leaks!

Chart Java Jitter with jHiccup
Monitor and identify pauses in your Java apps. Download now

Use jKool analytics as a service
Spot patterns in time-series data - real-time and free

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

See Your Message Here
You could have your tool advertised here, to be seen by thousands of potential customers

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:

AppDynamics: Get complete browser to backend visibility. Monitor Now!

New Relic
New Relic: Try free w/ production profiling and get a free shirt!

ManageEngine's Site24x7: End-to-End analysis on Java EE web transactions. Sign up for FREE!

Get rid of your performance problems and memory leaks!

Chart Java Jitter with jHiccup
Monitor and identify pauses in your Java apps. Download now

Use jKool analytics as a service
Spot patterns in time-series data - real-time and free

Sun announced laying off another 1,000 personnel. Does this matter to the Java world? Realistically, yes. Of course Java is much bigger than Sun, and would continue without them. But Sun still controls Java, still supports the core packages, and still sets the direction for Java despite the Java Community Process. For example, Java3D appears comatose, with the final two Sun Java3D developers having been sacked (see this month's news below). There will be other Java areas that are affected too.

The problem is, Sun doesn't make enough money from Java. Come on Sun, 3 million existing developers, more than half the enterprise projects under development, you should be able to come up with some way of making money out of that.

If you are one of our dozens of subscribers from IBM, there is a good chance you didn't get the emailed version of this newsletter. For some reason unknown to us, IBM rejects this newsletter, possibly as spam. I've tried to ask IBM postmasters about this, but get no response. If you can help us to help IBM subscribers get this newsletter, please email me.

In November, we will be providing Java Performance Tuning training in Hong Kong, at a customer site. If anyone else in Hong Kong would like to arrange any training or consulting while we are there, please contact us as soon as possible.

A note from this newsletter's sponsor

Brought to you by Veritas: Download your
"Risks of Performance Problems in J2EE Projects"
White Paper written by Jack Shirazi, Director of

We have all our usual sections, as well as the start of what I hope to be a new regular addition, a monthly article on some aspect of Java performance. This month Scot Mcphee writes about Timers and audio performance. This is only the second article I have ever seen on Java audio performance, and it is nice to be able to bring it to you. If anyone else out there has a contribution they would like to make to our new article section, I'd love to hear from you.

In our other sections, Kirk's roundup covers super computers, garbage collection in microbenchmarks, not threading EJBs, capacity planning, the variability of performance across systems, and more This month's interview is with Frank Cohen, the creator of the open source TestMaker webservices load tester. Our question of the month asks if turning off assertions is a bad practice.

Javva The Hutt has another installment of his diary, and tells us about what to expect in the 1.7 JVM (that'd be around 2007 or 2008) and, of course, we have many new performance tips extracted in concise form.


Java performance tuning related news.

A note from this newsletter's sponsor

Diagnose and resolve J2EE performance issues, now
even in production, with PerformaSure. Download the
META Group white paper, "Managing a J2EE World".


Recent Articles

See also our backlogged list of articles which lists all those articles that are of interest to the Java performance community, including those we have not had a chance to extract the tips from.

Jack Shirazi

The Roundup

With all of the emphasis on Intel and gigahertz clock speeds, you might think that the need for super computers (such as those that were produced by Cray) is a thing of the past. Though still a niche market, super computers and super computing research is alive and kicking. You can find the evidence at, at site that lists the top 500 super-computers. Take for example, the number one super computer according to the ISC: Earth Simulator.

In March of 2000, the Japan Atomic Energy Research Institute (JAERI), National Space Development Agency of Japan (NASDAJ), and the Japan Marine Science and Technology Center (JAMSTEC) started construction on the Earth Simulator super computer. This computer is dedicated to modeling the changes to atmosphere, oceans, and solid earth. By February 2002, all 640 processor nodes of the simulator were operational and the Earth Simulator Research and Development Center verified a sustained performance of 7.2 Teraflops. According to ISC at their 2003 super computing conference, the Earth Simulator, at 35.86 teraflops sustained, is now the fastest computer on the planet.

Even more interesting, Linux based clusters now comprise more than one third of the top 500 super computers, and the MCR Linux cluster (Xeon 2.4 GHz Quadrics cluster) running at 11.2 Teraflops at Lawrence Livermore National Laboratory ranks number 3 on the list . Though most feel that super computers based on off the shelf components will dominate the list, at least one expert, Horst Simon, has demonstrated that this strategy does have it?s limits. To further this point, companies like Acconovis, Cray and NEC still rely on proprietary processors and even many of the Linux clusters rely on proprietary inter-connect hardware.

As is always the case, the work done in this arena eventually does trickle down to our world, the business domain. Currently, much of this technology is being applied to Grid computing. This important move has not been lost on many of the software vendors including Oracle Corporation. Though clearly just a clever marketing ploy, with the 10g label, Oracle is in the process of rebranding all of their technology to match the march into this new form of high performance computing. Clearly, they see the future in the commoditization of these exotic clusters of hardware. But, beware of marketing because in order for software to take advantage of this new breed of hardware, it will need to undergo radical changes in design and architecture. But, this is not news; it?s a continuation of a trend that has always been with us. And with that note, lets move back to our reality by pulling up a chair at the Big Moose Saloon at the Java Ranch.

The JavaRanch

What is the name of that theory that after so many postings, the topic of discussion will have changed? Well anyway, what starts out as a discussion on how to store lots of integers turns into an interesting observation on the effects of garbage collection on a micro-benchmark. In this case, it was the code fragment below that brought an abrupt change in the topic of conversation.

  public long getFreeMemory() {
    // make sure to garbage collect before the measurement
    for (int i = 0; i < 10; i++) {
    Runtime r = Runtime.getRuntime();
    long freeMem = r.freeMemory();
    return freeMem;

In this code fragment, we see that System.gc() is called 10 times before free memory is measured. The question is, why should one repeatedly call System.gc()? After all isn?t once enough? It turns out that the answer is a bit complicated. The first point is that programmatically calling for a garbage collection is only taken as a hint. The VM is not actually required to perform a gc. Secondly, the call for garbage collection may only result in a partial collection. Consequently, many partials may be needed before garbage collection can be eliminated as a factor in your micro-benchmark. The one thing that I found to be missing is a call to sleep. Since garbage collection runs in it?s own thread, I?ve often found that sleeping for a short period of time (500ms to 1 second) allows the garbage collector to complete it?s job before I start in and take some measurements. On last point, using the ?verbosegc is quite necessary in the experimental stages as it will tell you if garbage collection is interfering with your benchmark.

Sometimes the best code is the code that we don?t write. That is the theme of a discussion that was triggered when someone asked about removing duplicates from a CSV file containing email addresses. In this case, performance over ?time to market? was even less critical as this was billed as being a one-time task. Here, performance is defined as the quickest solution that one can produce to solve the problem. To solve the problem, one could use a quick java program (put the values into a hashmap) or rely on an external tool such as a macro in excel (after all, the data is csv) or even use cygwin or Unix tools such as sort and uniq. In the end, this question is not about performance, it?s about getting results. Performance is about meeting a users requirement for delivering results in a timely manner. This may, or may not involve a lot of effort. One thing is for sure; the payback must be worth the effort or you're certainly misallocating resources, in this case, your time!

The Server Side

Though our first posting from the ServerSide is loosely related to performance, it does bring up some interesting points about EJBs. The question is poised around the observation that a log of high performance computing relies on asynchronous calls and threading. Why does the EJB specification specifically prohibit these mechanisms? One of the first responses suggested that message beans were there to provide this asynchronous mechanism. Though messaging can be used in this manner, it is a very heavy protocol to achieve this effect. And, it does not solve the problem of threading. The issue with threading stems from the need for the server to be able to manage it?s own resources. With threading, there is a distinct possibility that a caller may return and leave a thread running. This running thread (which is outside of the control of the container) would leave the server in a state where it was unable to manage resources. On top of this, EJB was designed to be a service-based architecture. The caller requested a service and then waited around until the service completed. In this model, one can still thread, just not in the server itself. Just to show how the technology is maturing, IBM is now working on asynchronous beans. Though they may add additional complexity, it?s clear that both threading as well as asynchronous capabilities may offer some nice performance gains for EJB technology.

If you believe that capacity/availability planning, is a black art, then you?re only somewhat correct. As is shown in one post, if you follow a number of guidelines, you can effectively plan for capacity and availability. As was posted in a response, one needs to characterize ?the nature of the workload.? This is usually quantified by determining the number of concurrent users, the type of work that they do, and how often they perform work. It was pointed out that the number of concurrent users may need to be translated into the number of requests made to the system. For example, one business operation may result in four round trips to the server. Once the average unit of work has been determined from the aforementioned information, one can estimate how much bandwidth, CPU, and I/O is required. From the answers to these questions, you can now begin to estimate how much hardware is required to host your application. One last point, be sure to include some space for growth and effective monitoring of a system can help with future capacity planning exercises.

At (now a community), there is a fascinating thread in which the results of a micro-benchmarking exercise are discussed. In this thread, the originator lays out results for a micro-benchmark that he performed. The tests uses 7 different techniques to calculate the cross product of 2 vectors. The thread (which can be found here) is too long to effectively summarize here but some of the main points are:

In another thread, a link to a benchmark that reportedly compares the relative speeds of C/C++, Java, and C# is published. This sparks a long discussion on the relevance of benchmarks in general when it comes to writing real world applications. One of Jack?s benchmarks even gets a mention (more on that later). The thread ends with two summaries that say about the same thing. Benchmarks stress a small number of aspects of a computing environment. On the other hand, applications may or may not place the same level of stress on that environment. So although benchmarks can be helpful in determining which techniques maybe effective in certain circumstances, they should not be the overall driving factor when making technology/design decisions. In other words, one should use the tools that are most appropriate for the job.

April Fools Joke Finally Revealed

In a side note on the benchmarking thread found at, Jack?s micro-benchmark that was published in April edition of this newsletter was cited. Proving that you can?t get anything past these guys, it was quickly pointed out that the benchmark is ?a rather witty practical joke.? Well, since Jack and I have had several emails on this benchmark, it?s time to come clean. Yes, the results from the benchmark are real and yes, one can interpret them as being misleading (and even a witty practical joke given that they were published on April 1st). But, from this benchmark, we can learn several valuable lessons, the first being that dynamic optimization is a very powerful tool. The second, is that you should know what you are actually benchmarking: it is not always what you intended to benchmark.

Kirk Pepperdine.

Javva The Hutt is not the only place where they interview people about performance (though their interviews are pretty close to the best I've seen, packed with useful and relevant info). I came across this excellent interview with Michael Widenius, one of the MySQL creators, talking about in-memory databases.

The basic premise is that RAM is now so cheap and available in such large configurations that you can store it all in memory. A multi-gigabyte database fits into RAM that costs just a few hundred dollars. The interview discusses the changes in database design that are needed to handle this mode of database operation.

But what leaped out at me was that you could take a running Java VM, and just store the data structures directly in memory rather than storing the data into a database. I mean if you are already supporting in-memory data structures, why go through conversion inefficiencies? You start your JVM, and just load a "database object" directly into the JVM with access to all the data in object structures. I guess this essentially becomes an object database rather than a relational database, and it would be immensely efficient.

I bet that in about two or three major versions, say by the 1.7 release, we will be able to specify alternate data storage locations for objects created by the JVM. Like a "short-life" memory, a "long-life" memory, a "no collect" memory and a "persistent" memory. Now that I think about it, I even seem to recall seeing a proposal along the lines of JVMs supporting multiple memory models somewhere (though I can't recall where). You specified the "current" memory and any objects created went into that currently specified memory. Yes, for sure this is coming.

You heard it here first.

Diary of a Hutt

July 2. Ugh, got a memo from Hilite. "Please note that the luminous sandwich in the fridge, room 232, is my property, and should not be tampered with. All bitemarks will be investigated using both dental records and DNA investigation. Taking property that is not yours is theft". The memo was, of course, hi-lited in lurid green. He must have spent days hi-liting all those memos. Everyone that I could see had one. Unbelievable.

July 9. I checked, and no one ever sees Hilite hi-liting his memos. He must take them home to do it. Hilite is uncannily close to a Dilbert character. Apparently it started when the spare wheel from his car was stolen. Someone told him that it's quite a common theft, and some people chain up their spares with a padlock, but that a few people spray paint the spare a color like shocking pink and that deters the thiefs. After all, if you are going to rip off a spare wheel, why go for the easily distinguished one when there are so many others - it usually happens in car parks. So Hilite sprayed his spare wheel, then decided it was such a good idea he started extending the idea. His shoes have wobbly green stripes on them, all his office equipment are marked, and now it seems his sandwichs are too (the wrapping, not the actual food).

July 16. Found out what Hilite uses to make his sandwich wrapping luminuous green. Interesting combination.

July 23. What a shouting match. Haven't seen one like that since Screamboy was told that his services were no longer required. Ouch, I still wince when I think of that one. His manager had to take a week off to recover and the security guards had to drag Screamboy out of the building, still shouting after four hours of continuous expletive laced graphic imagery about his boss's assumed after hours proclivities. This time it seems that Hilite's sandwich disappeared. And with the lights off in the evening luminuous green was clearly visible on Weevil's desk. Hilite was screaming at Weevil, Weevil was screaming back at Hilite, Frezian was screaming at both of them, and the rest of the floor were encouraging them all. There's no business like the I.T. business, not even show business.


Javva The Hutt.

The Interview: Frank Cohen

This month we interviewed Frank Cohen, creator of the open source TestMaker web application load tester, aimed at Web Service load testing.

JPT: Can you tell us a bit about yourself and what you do?

I'm the "go to" guy for enterprises that need to understand and solve scalability problems in their information systems, especially in Web Services. I founded PushToTest in 2001 to provide services to enterprises and to be the center of the TestMaker community. TestMaker is an open-source test tool I created in 1997 and continue to maintain that checks Web-enabled applications for scalability, functionality, and performance. The TestMaker community is now 42,000 strong and we regularly send newsletters and surveys to our 3,200 registered users.

JPT: What do you consider to be the biggest Java performance issue currently?

The biggest Java performance issue currently is the uncertainty of how Web Services will impact overall system performance. In my view, J2EE 1.4 is primarily a Web Service focused release. It tells the J2EE using audience to expect XML encoded data in everything they do - Application Programming Interfaces (APIs), communication protocols, Web page flows, security protocols, and data persistence. XML is neither compact nor concise. So we can expect to see Web infrastructures (TPC/IP routed networks moving HTTP traffic containing XML-encoded data) to acheive new levels of usage. The CPU bandwidth needed to support XML data serializers and the TCP/IP networks will become the new bottlenecks to good performance. By 2005, with wide adoptance of second generation Web Service standards (WS-Security, WS-Reliability, SAML, WSDL 1.1, etc.) we will see performance issues move up into the stack as complex XML datatypes need to be encoded and decoded in the CPU.

The existing performance enhancement tools and debuggers will need to be extended to show how a J2EE 1.4 or greater application performs under load. And yet, these debuggers have no facility to create the same load a real user creates in a production setting. This paradox will become the biggest Java performance issue in the near future.

JPT: Do you know of any requirements that potentially affect performance significantly enough that you find yourself altering designs to handle them?

In Web-enabled applications that require synchronization of data that comes from multiple sources, I have had to alter system designs to provide for data replication from one data center to another. For example, in my last start-up company, Inclusion Technologies, we had to change our original designs for a secure collaborative extranet application server to use a persistent message store-and-forward protocol, rather than building the system around a single database server.

It was very popular over the past 5 years to think a Java Web-enabled application would instantly scale by putting a load balancer between the end-user and a Web application server. Today, clustering technology is important for large systems. Clusters can share data caches and session identification markers.

JPT: What are the most common performance related mistakes that you have seen projects make when developing Java applications?

Most of the performance related mistakes I see in Java code comes when PushToTest conducts a datacenter certification. This is where we certify that the customer has enough servers, software, storage and network bandwidth to handle a defined number of users - for example, the University with 12,000 students returning from their summer break that installed a new email server. What I often find in Java code is concurrency problems - the code works fine with a few users but breaks with many users. The problem is usually related to unnecessary global variables that are never released and consequently never garbage collected, threads that never terminate even after their workflow is completed, and thread deadlocks that happen after a dependent thread - such as a log handler - goes into a busy state and never returns.

JPT: Which change have you seen applied in a project that gained the largest performance improvement?

The largest performance improvement I found recently was in SOAP encoded styles in a Java Web service. By changing a Java Web service to use Document-literal encoding from SOAP RPC encoding, the application ran 3100% faster. See: for details and sample Java code.

JPT: Have you found any Java performance benchmarks useful?

No. I am still waiting for a benchmark that models real world usage against a user's goals. In the real world, users of a J2EE application use Web pages, email messages, database services and more (all the APIs that come in J2EE,) yet I don't see a benchmark that uses all these APIs and shows how well the system performed against the user's goals.

JPT: Do you know of any performance related tools that you would like to share with our readers?

My own open-source test tool (TestMaker, found at would be nothing without the support of many other tools and libraries, including Jython (the Python language implemented 100% in Java,) JDOM (the ultimate Java-friendly way to work with XML data, and also JSR 104,) NetBeans (the IDE and application development framework from Sun,) MaxQ (a proxy recorder that watches you use a browser to operate a Web application and writes a Jython-based test script for you,) and JOpenChart (a cool Java package to visualize the test results in a set of line and bar charts.) All of these are integrated into TestMaker.

JPT: Do you have any particular performance tips you would like to tell our readers about?

I have lots of tips that appear in my upcoming book from Prentice Hall. Advance chapters are available for download at

JPT: Thank you for the interview.

Thanks for the opportunity to answer your questions. -Frank

(End of interview).

Question of the month

In the book "Java Performance Tuning" (O'Reilly), you suggested turning off all assertions for production code. Isn't this bad practice? Some error checking is required in production code.

I agree that deployed code should retain as much error checking as possible. But "Java Performance Tuning", whether we are talking about the book, the website, or the general subject, is not always about optimal software practices. Java performance tuning is usually needed in the situation where you have already applied best practices, and unfortunately performance is not adequate. In my book and on this website I show practices which optimize performance, whether or not such practices are also "best practice". This is of course, dangerous, as more than one person has noted. Java performance tuning is about making tradeoffs to speed things up. It is unfortunate that tradeoffs are needed, but best practices aren't quite enough to get adequate performance in all situations.

While some performance tuning techniques are also best practice techniques, most performance tuning techniques force you to choose between good software practice and better performance; some performance tuning techniques are really "last choice practice", the antithesis to best practice. It is unfortunate that this is the case. This is one of the reasons why you should really only tune where necessary, i.e. where a performance problem has been identified, not guessed at.

I once extracted those performance tuning recommendations which were also best practices for a couple of "best practice" O'Reilly books. The resulting volume of text was about a tenth of my book. A guess that only one in ten performance tuning techniques is compatible with best practice programming is probably a good guess. But that doesn't mean that 90% of your application will be compromised. You normally only need to apply tuning techniques in small selected portions of an application, so keep using those best practices and leave tuning to when it's necessary.

To get back to your original point about turning off assertions for production, if you identify that assertions are causing a performance bottleneck, then selectively turning them off is a valid performance tune. Chances are that you will only need to turn off some assertions, those in the bottlenecked section of the code. But if your application is liberally laced with assertions throughout the code, it may be the sheer volume of assertions causing a performance problem, in which case you may have to turn them all off by default, and selectively enable those that are really essential for the production system. This is a typical type of tradeoff you make when performance tuning.

The team

Tips JMS Application Architectures (Page last updated August 2003, Added 2003-09-30, Author Roland Barcia, Publisher TheServerSide). Tips: Hyperthreading Java (Page last updated August 2003, Added 2003-09-30, Author Paul Bemowski, Publisher JavaDevelopersJournal). Tips: Fast math with JNI (Page last updated August 2003, Added 2003-09-30, Author Jeff S. Smith, Publisher JavaWorld). Tips: Referencing objects (Page last updated August 2003, Added 2003-09-30, Author Jack Shirazi Kirk Pepperdine, Publisher IBM). Tips: BufferedImage as Good as Butter (Page last updated August 2003, Added 2003-09-30, Author Chet Haase, Publisher Tips: BufferedImage as Good as Butter II (Page last updated August 2003, Added 2003-09-30, Author Chet Haase, Publisher Tips: Profiling the profilers (Page last updated August 2003, Added 2003-09-30, Author Laurence Vanhelsuw? , Publisher JavaWorld). Tips: Living with [Abstraction] Leaks (Page last updated July 2003, Added 2003-09-30, Author Craig Castelaz, Publisher Tips: Performance of Java Compilers (Page last updated July 2003, Added 2003-09-30, Author Haralambos Marmanis, Publisher JDJ). Tips: Optimizing the Client/Server Communication for Mobile Applications, Part 1 (Page last updated July 2003, Added 2003-09-30, Author Forum Nokia, Publisher Nokia). Tips:

Jack Shirazi

Last Updated: 2014-12-01
Copyright © 2000-2014 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