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. 7, June 18th, 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 I've added a new section on Java performance related news items. In the future this section will include any updates to existing tools, vendor announcements, benchmark reports, etc. Also newsworthy is that the resources page has been restructured to add two profiling tools sections, (Free) Profiling Tools and (Not Free) Profiling Tools. I was surprised to find out how many free resources there are.

This months articles have no real theme, except perhaps to show how widely used Java is. Kirk adds the newish discussion group at to his roundup of the Java performance tuning discussion groups. But there's no update on his banana tree this month.

Finally, my usual reminder to our Japanese readers that Yukio Andoh's translation should be available at in a week or so.


Java performance tuning related news.

Recent Articles

All the following page references have their tips extracted below.

Older Pages

All the following page references have their tips extracted below.

Other additions to the website


Discussion groups

Jack Shirazi

Kirk's roundup

If there is any group of developers that knows how to squeeze out every ounce of performance, it has to be gamers. Anyone remember the original flight simulator? How about Snipes, one of the first network based, interactive shoot-em-up games. The guy with the bigger hardware always seemed to have the upper hand. Because I always seemed to be the one with the slowest hardware, I quickly came to appreciate how performance affects the gaming experience. So, it is not surprising to find that a site such as supports a discussion group focused on performance. I'll start this months roundup with a review of this site.

The discussion group at is organized a little differently than is the JavaRanch and theServerSide. At the outset, it resembles wiki but, once you tunnel down, you'll find the familiar "by topic" message flow. My first random walk though the links led me to a nice description of garbage collection (GC) from Jeff Kessellman. In a very dense message, Jeff dispelled the notion that reference counting was being used in the HotSpot VM. Jeff explained that a full GC is performed before the VM will throw an out-of-memory error. He also provided a nice recipe on how to find object leaks in your application. But that wasn't the end of Jeff's contribution to the list (as we'll see later on).

My wanderings through got less random when I saw a thread entitled "Ugly memory tricks in 1.4 beta". I must say that even though the thread was short and simple, I needed to walk away from my desk and think about it for a while. The code segment presented below prints "2" and "os".

String osv = "Osvaldo"; 
sun.misc.Unsafe.getUnsafe().putInt(osv, 16, 2); 

Jeff Kesselman pointed out that the unsafe class is suppose to provide direct access to native memory without needing to use the JNI. Apparently, the implementation can only be used from privileged code and does perform bounds checking. Even so, this is a class I'm sure I'm not going to be using any time soon. While you're out checking "Java's Newest Trick -- THE UNSAFE CLASS!" posted on the Java lobby site by Osvaldo Doederlein, I'll be brushing up on my SEGV debugging skills (core dump territory, for those of you who have had the good luck to miss out on SIGSEGV - ed.).

One thread started off with a discussion of pooling/synchronization vs. object creation in which Jeff provided some valuable information on the effects of local cache on the CPU on multi-threaded applications. The V9 Sparc introduced four new fetch/cache instructions to help with threading and performance. This change broke several of the pre-V9 VM implementations as it caused different threads (or in some cases, the same thread) to maintain different copies of data in local cache, which in turn created cache coherency bugs. As it turns out, this problem is not isolated to the Sparc CPU. As is generally the case when there is a discussion on pooling, the subject quickly turned to the cost of synchronization. Jack described the differences between method and block synchronization (which I covered in last months newsletter) and some interesting information on cache coherency (see Art Jolin's "Java's Atomic assignment" article in Java Report Aug 1998 p27). Jack commented that method synchronization was faster than block synchronization in every VM that he has tested. It was at this point that Jeff laid down the gauntlet and a spirited and most informative debate between Jeff and Jack began. The primary question was: should one make VM/hardware specific optimizations? Jeff took the position that one should focus on WORA optimizations. Jack argued that many useful optimizations often take advantage of VM/hardware specific features. IMHO, the clinching argument was made when Jack took an I/O example from Jeff?s book and explained how it was a hardware specific optimization. My personal experience is from a number of target environments that are quite diverse. Aside from making sure that I use strong algorithms, I often implement hardware/VM performance enhancements as these frequently provide the best performance boost. Using plug-in points (pg 25, "Java Color Modeling with UML", Peter Coad, Eric Lefebvre, Jeff DeLuca) one can often isolate these optimizations.

Lets look at what's happening down on the Java Ranch. The question that caught my eye concerned an out-of-memory error caused by a heap that kept growing. Of course, increasing the heap size helped delay the problem, but did not prevent it. The obvious advice given was that objects were not being released. It was suggested that a profiler be used. One important fact: the application was running in TomCat, which implies that the client is running a browser. So, is the answer really that simple? What happens if the objects are collecting in the HTTP session state? How do you know when a user is finished with his/her session state? VM bloat is common in systems where the interface between the client and the data is a servlet. So, the profiler will tell you that you're holding onto too much data. It won't tell if the user is finished with it (unless the user logs out of course).

Here is an interesting but yet unanswered question concerning the KVM. Are sockets slower on the KVM? Although my experience with the KVM is limited, it does include experimentation with sockets all be it on a Palm Vx wired to a PC. Since the amount of data that I was passing was small, I didn't notice any performance problems. The Palm Vx did not open a socket. A server daemon did this for it. The Palm Vx used a hot-sync like connection to connect with the server. I may be wrong but, I suspect that a moderately higher load would strain this type of link. Maybe someone with more experience could comment on this.

What?s new from The Server Side? We start with a question concerning the scalability of the BSD VM. Unfortunately, it doesn't do so well according to the Volano benchmark. You can find these and other results at

It is common when using EJBs to map an Entity Bean to a row in a table. This can result in the EJB server creating a large number of Entity Beans when the table is large, or when you need to look at the entire table. One such participant was asking how one should deal with this problem. A solution that is commonly used is known as bi-modal access. In a bi-modal architecture, Session Beans provide read-only access to the db. All read/write operations are performed by Entity Beans. A follow up question was, why use Entity Beans at all? The response: writing all the JDBC code was time consuming. Using Entity Beans solves this problem and a few others.

This column wouldn't be complete if we didn't somehow mention JavaOne. I did not attend JavaOne, but I did watch the keynotes. It was particularly interesting to see James Gosling introduce asserts and generics. I must say that I'm not a big fan of writing code to downcast. I also don't like the performance hit that casting extracts. Given this, one would think that I would applaud the introduction of generics into the language. But, unlike Mr. Gosling, I'm not happy that generics are being introduced into the language. Why? Because, Java does not need any more syntax and what do generics do? Introduce more syntax. The object already is being returned to a typed holder. The object itself is typed. If the types don't match, then throw a ClassCastException. The only loss is that you can't restrict which objects get inserted into a collection. Is this feature worth the extra syntax? You know my opinion, lets hear yours.

Kirk Pepperdine.

Comparing the performance of LinkedLists and ArrayLists (and Vectors) (Page last updated May 2001, Added 2001-06-18, Author Jack Shirazi). Tips:
"Cutting Edge Java Game Programming". Oldish but still useful intro book to games programming using Java. (Page last updated 1996, Added 2001-06-18, Author Neil Bartlett, Steve Simkin ). Tips:
Tutorial on the full screen capabilities in the 1.4 release (5 pages plus example pages under the top page) (Page last updated June 2001, Added 2001-06-18, Author Michael Martak). Tips:
Various performance tips (Page last updated May 2001, Added 2001-06-18, Author Asha Balasubramanyan). Tips:
Timing out sockets (Page last updated 2000, Added 2001-06-18, Author David Reilly). Tips:
Load testing of web applications (Page last updated June 2001, Added 2001-06-18, Author Frank Cohen). Tips:
J2EE design patterns to improve performance (Page last updated June 2001, Added 2001-06-18, Author Daniel H. Steinberg). Tips:
Moving from JSP to EJB (Page last updated June 2001, Added 2001-06-18, Author Patrick Sean Neville). Tips:
Judging various aspects of Java, including performance (Page last updated May 2001, Added 2001-06-18, Author Brian Maso). Tips:
Experiences building a servlet (Page last updated June 2001, Added 2001-06-18, Author Asif Habibullah, Jimmy Xu). Tips:
Sun presentation on J2SE performance strategies (originally accessed from Reginald Hutcherson's page) (Page last updated May 2001, Added 2001-06-18, Author Reginald Hutcherson). Tips:
Optimizing recursive methods (Page last updated June 2001, Added 2001-06-18, Author Eric E. Allen). Tips:,,12082_778571,00.html
Java collections (Page last updated June 2001, Added 2001-06-18, Author Richard G. Baldwin). Tips:
Computational planning and scheduling problem solving (not performance tuning) (Page last updated June 2001, Added 2001-06-18, Author Irvin Lustig). Tips:

Jack Shirazi

Last Updated: 2022-06-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