JProfiler Get rid of your performance problems and memory leaks! Modern Garbage Collection 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 JProfiler 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 TheServerSide.com 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.

• Optimizing hash functions (OnJava)
  
• CachedRowSet, a ResultSet that doesn't need continuous connection to the database (JavaWorld)
  
• Sun community chat session on "Optimizing Java Program Performance" with Peter Haggar (Sun)
  
• Sun community chat session on "Threading and Concurrency in the Java Platform" with Thomas Christopher and George Thiruvathukal (Sun)
  
• Chapter 3 of "High Performance Java Computing : Multi-Threaded and Networked Programming", "Race Conditions and Mutual Exclusion" (Sun)
  
• Chapter 4 of "High Performance Java Computing : Multi-Threaded and Networked Programming", "Monitors" (Sun)
  
• Choosing a J2EE application server (Java Zone)
  
• Designing for performance (JavaWorld)
  
• Sun engineering report on performance testing JVMs (Sun)
  
• Performance tuning report in German (Bastie)
  

Older pages

All the following page references have their tips extracted below.

• JDBC performance (JGuru)
  
• iPlanet Web Server guide to servlets (iPlanet)
  
• Connection pools (Web Developers Journal)
  
• HotSpot FAQ (Sun)
  

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.

• http://www.weblogic.com/docs51/admindocs/tuning.html
• http://jbspc.cs.unc.edu/D/MySoftware/www/servers/WebLogic/docs/classdocs/API_jdbct3.html
• http://www.weblogic.com/docs51/techdeploy/jdbcperf.html
• http://www.ymtech.co.kr/En/catalogue~/WebLogicServerTuningGuide6.html
• http://www.weblogic.com/docs51/techoverview/rmi.html
• http://www.techmetrix.com/trendmarkers/tmk0400/tmk0400-4.php3
• http://newsgroups.bea.com/cgi-bin/dnewsweb?cmd=xover&group=weblogic.developer.interest.performance&utag=

Other additions to the website

http://www.electronicstimes.com/story/OEG20010131S0032
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, www.TheServerSide.com 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 http://java.oreilly.com/news/javaperf_0900.html and http://www.javaworld.com/javaworld/jw-11-2000/jw-1117-optimize.html.

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.

Tips

http://www.onjava.com/pub/a/onjava/2001/01/25/hash_functions.html
Optimizing hash functions: generating a perfect hash function (Page last updated January 2001, Added 2001-02-21, Author Jack Shirazi). Tips:

• perfect hash functions guarantee that every key maps to a separate entry in a hashtable, and so provide more efficient hastable implementations than generic hash functions.
• perfect hash functions are possible when the key data is restricted to a known set of elements.
• Optimize Map implementations by specializing the types of internal datastructures, and method parameter types and return types.
• Optimize Map implementations by using a specialized hash function that is optimized for the key type, rather than generic to all possible types of keys.
• Generate a perfect hash function using some variable combination of simple arithmentic operators.
• Perfect hash functions may require excessive amounts of memory.
• Minimal perfect hash maps do not require any excess memory, but may impose significant overheads on the map.

http://www.javaworld.com/javaworld/jw-02-2001/jw-0202-cachedrow.html
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:

• CachedRowSet provides cached result sets that do not require continuous connection to the database, allowing connections to be reused more efficiently.
• Using CachedRowSet lets you batch updates, and execute them asynchronously.
• CachedRowSet also supports offline work which is later synchronized.
• CachedRowSet is probably not appropriate for managing large datasets.

http://developer.java.sun.com/developer/community/chat/JavaLive/2001/jl0131.html
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:

• Try faster JVMs if possible.
• Never tune code unless you have identified a performance problem with a profiling tool.
• Beware that tuning techniques may not work well on all platforms.
• Speed start-up time by: minimizing the .class sizes (use -g:none or a shrink tool e.g. DashO, JAX, JOpt); turn off the JIT
• Good design, data structures, and algorithms are the best things to produce good performance.
• Check String manipulation code.
• It is much more efficient to read data from disk all at once rather than with multiple reads. Use the buffered classes when doing i/o.
• import is a compile time function, so has no effect on runtime (i.e. import a.b.*; or import a.b.c; make no difference to runtime performance).
• Optimize conditionals to have the most likely true results first.

http://developer.java.sun.com/developer/community/chat/JavaLive/2001/jl0109.html
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:

• If memory is at a premium, the cost of allocating a Thread object and allocating a stack can be expensive.
• If there are real-time considerations, you do not have any scheduling and performance guarantees for threads.
• Be careful about the number of threads you create: too many and you can exhaust your memory: too few and you don't get the advantages of parallelism.
• Use javax.swing.SwingUtilities.invokeLater() [java.awt.EventQueue.invokeLater()] to schedule work onto the awt thread.

http://developer.java.sun.com/developer/Books/performance2/chap3.pdf
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:

• Execute I/O in blocks rather than one byte at a time.
• I/O reads are normally faster than writes. This means that I/O performance can be improved by decoupling reading and writing to dedicated threads, rather than interleaving reads and writes.
• INVALID: NOTE THE TIP "volatile primitive datatypes cannot be cached, and have a write-through update policy allowing atomic read-writes, i.e. x++ is an atomic operation if x is volatile." HAS BEEN SHOWN TO BE INVALID.
• [The chapter describes implementations for lock objects (wait until unlocked), counting semaphore objects (wait until positive), barrier sempahore objects (wait until last thread is finished), future objects (wait until a variable is first set). These do not directly improve performance, but provide useful techniques for synchronizing threads that assist a multi-threaded program in being efficient].
• Use resource enumeration (acquire resources in a set order) to avoid deadlocks.

http://developer.java.sun.com/developer/Books/performance2/chap4.pdf
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:

• Java monitors are not necessarily the most efficient synchronization mechanism, especially if transferring the lock can lead to a race condition [chapter discusses a more complete Monitor class].
• volatile fields can be slower than non-volatile fields, because the system is forced to store to memory rather than use registers. But they may useful to avoid concurrency problems.
• [The chapter discusses various policies for synchronizing threads trying to read from or write to shared resources, which provide different scheduling policies: one thread at a time; readers-preferred (readers have priority); writers-preferred (writers have priority); alternating readers-writers (alternates between a single writer and a batch of readers); take-a-number (first-come, first-served)].

http://www.java-zone.com/free/articles/sf0101/sf0101-1.asp
Choosing a J2EE application server, emphasizing the importance of performance issues (Page last updated February 2001, Added 2001-02-21, Author Steve Franklin). Tips:

• Application server performance is affected by: the JDK version; connection pooling availability; JDBC version and optimized driver support; caching support; transactional efficiency; EJB component pooling mechanisms; efficiency of webserver-appserver connection; efficiency of persistence mechanisms.
• Your application server needs to be load tested with scaling, to determine suitability.
• Always validate the performance of the app server on the target hardware with peak expected user numbers.
• Decide on what is acceptable downtime for your application, and ensure the app server can deliver the required robustness. High availability may require: transparent fail-over; clustering; load balancing; efficient connection pooling; caching; duplicated servers; scalable CPU support.

http://www.javaworld.com/javaworld/jw-01-2001/jw-0112-performance.html
Article on designing for performance focusing on interfaces (Page last updated January 2001, Added 2001-02-21, Author Brian Goetz). Tips:

• Avoid excessive object creation: be wary of object creation inside of tight loops when executing performance-critical code.
• Performance-conscious programmers avoid excessive use of String.
• Defining a utility class which is applied to data required by its constructor means that you must create a new object for every piece of data to run it on. Instead, do not require data in the constructor.
• Do not force methods to provide arguments with input in the form that is convenient rather than efficient. For example, don't require that arguments be passed only as String objects if a byte array or char array would also be functionally equivalent (try to support all formats, especially the efficient ones).
• Defining an interface in terms of an interchange type (the type of object passed from a caller method to the callee method as an argument) reduces the interface's complexity while maintaining its flexibility, but sometimes this simplicity comes at the cost of performance.

http://developer.java.sun.com/developer/technicalArticles/Programming/JVMPerf/
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:

• Different versions of the Sun JVM support different optimization flags. Some flags may allow you to configure the garbage collector generational spaces.
• Configure heap space using -Xms and -Xmx [-ms and -mx for 1.1.x JVMs] to optimize the JVM heap memory for improved performance.
• If the JVM supports configuring the garbage collector generational spaces (-Xgenconfig in 1.2.2; -XX:newSize, -XX:MaxNewSize, -XX:SurvivorRatio in 1.3), then you can improve performance by specifying generation spaces more appropriate for your application [you can start with some appropriate configuration depending on the ratios of short-lived to medium-lived to long-lived objects, then test multiple configurations to determine the optimal config].
• The 1.3 JVM appears to be faster when run with the -server flag.
• The -Xoptimize flag seems to improve performance on those 1.2.x JVMs that support it.

http://www.jguru.com/jguru/faq/view.jsp?EID=131579
Discussion on JDBC performance (Page last updated August 2000, Added 2001-02-21, Author Swarraj Kulkarni). Tips:

• Use a connection pool mechanism whenever possible.
• Use prepared statements.
• Use stored procedures.
• Select only required columns rather than using select * from Table xyz.
• Always close Statement and ResultSet objects as soon as possible.
• Work with DatabaseMetaData to get information about database functionality.
• Always catch and handle database warnings and exceptions.
• Time DB queries.
• Use the most appropriate datatype specific kinds of data, e.g. store dates as a date type rather than varchar.
• Use scrollable ResultSet (JDBC 2.0).
• Stay away from the JDBC-ODBC and other Type 1 drivers where possible.

http://www.bastie.de/resource/res/mjp.pdf
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:

• [Report is in German. I'd be delighted if someone extracted the tips].

http://docs.iplanet.com/docs/manuals/fasttrak/41/servlets/1-using.htm#17322
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:

• Try to optimize the servlet loading mechanism, e.g. by listing the servlet first in loading configurations.
• Tune the heap size.
• Keep the classpath short.

http://www.webdevelopersjournal.com/columns/connection_pool.html
Article on connection pools (Page last updated September 1999, Added 2001-02-21, Author Hans Bergsten). Tips:

• Reuse database connections using a connection pool.
• Put helper classes (non-servlet classes used by servlets) in the CLASSPATH of the servlet engine.

http://java.sun.com/docs/hotspot/PerformanceFAQ.html
HotSpot FAQ (Page last updated August 2000, Added 2001-02-21, Author ?). Tips:

• HotSpot has a bunch of startup options that may help you configure your VM to go faster.
• HotSpot garbage collection parameters can be tuned with -Xincgc, -XX:NewSize, -XX:MaxNewSize and -XX:SurvivorRatio(and heap size parameters).
• Sun recommends you no longer use objects pools [this is rather a sweeping and inappropriate statement. Object pools are still useful even with HotSpot, but presumably not as often as previously].
• Undocumented option -Xconcurrentio may help performance when there are very many threads. It uses a lighter thread synchronization model.
• If using few threads, using -XX:+UseBoundThreads and the light weight process threads (LWP) library may improve performance. LWP threads are scheduled by the JVM, system threads have kernel scheduling.
• Don't call System.gc().
• Warming loops is no longer necessary from HotSpot 2.0 (SDK 1.3). HotSpot now supports on-stack-replacement.
• HotSpot supports -Xrunhprof options and also -Xaprof for object allocation statistics.
• Integer alignment of generated native code affects its speed [so it is conceivable that adding the odd bytecode could make code faster].
• HotSpot can eliminate "dead variables" and dead code, i.e. variables that are assigned to but never used [in isolated code segments].
• The generational-GC per object costs varies depending on the length of life of the object.

Jack Shirazi