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. 3, February 21st, 2001

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 a nice mixture of pages have appeared, ranging from chapters of a high performance threading book; to chat sessions on performance; a HotSpot FAQ; and a report on tweaking the internals of the JVM GC spaces; with lots more nice tips as well. And Kirk continues with his roundup, this time adding to his visited sites.

Next month, apart from the usual mix of new and old web pages, I'll be pulling together tips on Weblogic as my search agent has thrown up a bunch of these. For those of you who need the pages now, I've listed the URLs below.

Articles and other pages

All the following page references have their tips extracted below.

Older pages

All the following page references have their tips extracted below.

Weblogic pages for next month

These pages will be summarized next month. I've included the URLs here before I've had time to do the usual summary because Weblogic tuning is one of the most frequently requested searches that are directed to the Java Performance Tuning site.

Other additions to the website
Report on the Insilicon Java coprocessor

Jack Shirazi

Kirk's roundup

I would like to dedicate this month?s column in memory of Dale Earnhardt Sr., who died in a crash at the Daytona 500 while in the pursuit of performance. Dale was a person that had a deep understanding of the systems that he worked with. It was this understanding that made him one of the all time best racecar drivers. We should all be fortunate enough to have as deep an understanding of the systems that we work as he had, even though the results of our failures may not be so tragic.

The Server Side

The web site, is operated by The Middleware Company. Ed Roman, the founder of The Middleware Company, told me that he has assigned people to maintain and update the information found on the site. The result is a web site rich in information that is both topical and durable. The site supports several discussion groups, including one dedicated to performance.

One of the threads discussed recommendations for stress testing tools. The respondents provided a list that includes Loadrunner (Mercury), JMeter (Apache), Webload (IBM), Web Application Stress (Microsoft), OpenSTA (OpenSTA) and SuperStress of Super (Acelot). To this list, I would add Silk Performer (Segue Software). The question is, which one should you choose? One set of criteria lies in the type and composition of the application that your trying to test. For instance, if you're testing a J2EE application, then you might find it helpful if you can stress the persistence layer in isolation from the web server. Better to determine this up front rather than waiting to find out that your stress-testing tool doesn?t support your particular product/component mix.

There were also two interesting questions regarding threading. The first considered the usefulness of native threading on a system with a single CPU. I suspect that native threading will always be faster than using green threads though I have no facts to support this: I would be interested in hearing from anyone with concrete information.

The second threading discussion considered the number of threads per VM. In theory, one would think that you could run as many threads as the hardware would support. In practice, this seems not to be the case. There appears to be a maximum number of threads that will run in a typical JVM (about 70) and a maximum number of JVMs per CPU (about 2) before you start seeing a performance degradation. This discussion should have further to go.

One excellent piece of advice appeared during a discussion of scalability and availability of an EJB server. The writer advised developers to use a good object to relational mapping tool to start with, then later find your bottlenecks and optimize the RDB access using stored procedures or other techniques. This allows you to reap all of the productivity gains from the mapping tool, while still allowing performance to be addressed using bottleneck discovery. A perfectly sensible approach to take.

The JavaRanch Performance Round-up

Saddle up your VM ?cause it?s gonna be running at a full gallop after reading this months fare.

First, the question of the month, is Java a redundant technology? The answer is, I see nothing in Java that I?ve not seen elsewhere. What makes Java unique is in how it bundles all of these different ideas. For this characteristic, we can only thank the original authors of the language.

Does compiling Java classes to binary native executable increase performance? Without thinking about how this is done, one might think that the answer would be a resounding yes. But responders to this question reported seeing a decrease in performance. The rumor running around the saloon was that at best, one would only see the same performance in the executable as that demonstrated in the Java application. Thus, performance may not be the driving consideration when deciding on whether to compile your Java application to a native executable. One person did point out that they considered executables much easier to deploy.

A summary of a discussion on serialization is that serialization has huge overheads in having to paw through private stuff via the JVM that is normally unavailable, and also with all the reflection it uses. Externalization uses simple method calls: there is no overhead to the calls to your methods, and it normally works out faster.

What can javac do to for you? This started out as a "which code runs faster?" question but quickly turned into an interesting discussion about the state of compilers and what (if any) optimizations that a compiler can provide. In the end, all agreed that the ability of Java compilers to perform optimizations is still in its infancy. And currently javac doesn't optimize much.

What should you use for EJB applications, Session Beans or Entity Beans? What are the performance implications? As is the case whenever you add a layer to your applications architecture, there is a performance penalty to pay. So why add the layer? There are many reasons that are usually centered around design issues. It is generally thought (but not proven) that stateless Session Beans offer better scaling characteristics. The reason for this is that in EJB parlance, stateless Session Beans carry no conversational state. These server entities are shareable amongst several clients so in theory, the server requires fewer resources to manage its clients. The problem is, most services require state, which would appear to limit the usefulness of stateless Session Beans. But, there is an interesting proto-pattern that eliminates this apparent problem. The basis for the pattern is to code your queries in your service layer in stateless Session Beans. Instead of returning the result set to the client, the stateless Session Bean creates an Entity Bean to wrap the return set. A handle to the Entity Bean is returned to the client. The client can pick through the return set at its leisure.

What is more performant than JSP? How about handing rolling your own Sevlets. JSP relies on some one else?s parser so speed will depend upon how good that parser is. But since using JSP presumably speeds development time, the pragmatic approach would be to use JSP until you see that you have a performance issue in this layer.

The discussion on iterating over unchanging collections demonstrated a number of interesting techniques that eliminated the need to cast. But as is often the case, the simple solution was ignored. In this case, the simple solution is to let the collection perform the search. For details see and

Several questions were asked about which coding technique helps produce a more performant application. A number of people had lots of fun sitting in the Saloon bringing up points and counter points. The answers to each question led to a discussion of the underlying implementation of the VM and dependent classes and in some cases, how this was all tied to the underlying OS/hardware. Thus, the discussions were a lot to fun to read. I?m surprised that they missed the obvious answer to measure a running prototype or test case to find the answer. To be fair, Peter Hagger did offer a test case for one of the questions. One thing to be aware of is that many CPUs don?t directly support floating-point arithmetic. On these machines, math with integers will always be faster.

Kirk Pepperdine.

Optimizing hash functions: generating a perfect hash function (Page last updated January 2001, Added 2001-02-21, Author Jack Shirazi). Tips:
Article on using CachedRowSet, a ResultSet that doesn't need continuous connection to the database (Page last updated February 2001, Added 2001-02-21, Author Taylor G. Cowan). Tips:
Sun community chat session on "Optimizing Java Program Performance" with Peter Haggar. (Page last updated January 2001, Added 2001-02-21, Author Edward Ort). Tips:
Sun community chat session on "Threading and Concurrency in the Java Platform" with Thomas Christopher and George Thiruvathukal (Page last updated January 2001, Added 2001-02-21, Author Edward Ort). Tips:
Chapter 3 of "High Performance Java Computing : Multi-Threaded and Networked Programming", "Race Conditions and Mutual Exclusion" (Page last updated January 2001, Added 2001-02-21, Authors George Thiruvathukal, Thomas Christopher). Tips:
Chapter 4 of "High Performance Java Computing : Multi-Threaded and Networked Programming", "Monitors" (Page last updated January 2001, Added 2001-02-21, Authors George Thiruvathukal, Thomas Christopher). Tips:
Choosing a J2EE application server, emphasizing the importance of performance issues (Page last updated February 2001, Added 2001-02-21, Author Steve Franklin). Tips:
Article on designing for performance focusing on interfaces (Page last updated January 2001, Added 2001-02-21, Author Brian Goetz). Tips:
Sun engineering report on performance tests of various configurations of the 1.2.2 and 1.3 JVM (Page last updated February 2001, Added 2001-02-21, Author Ed Ort). Tips:
Discussion on JDBC performance (Page last updated August 2000, Added 2001-02-21, Author Swarraj Kulkarni). Tips:
Performance tuning report in German. As I don't speak German, it is difficult for me to comment any further (Page last updated December 2000, Added 2001-02-21, Author Sebastian Ritter). Tips:
iPlanet Web Server guide to servlets, with a section at the end on "Maximizing Servlet Performance". (Page last updated July 2000, Added 2001-02-21, Author ?). Tips:
Article on connection pools (Page last updated September 1999, Added 2001-02-21, Author Hans Bergsten). Tips:
HotSpot FAQ (Page last updated August 2000, Added 2001-02-21, Author ?). Tips:

Jack Shirazi

Last Updated: 2022-11-29
Copyright © 2000-2022 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