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!

If last month was characterized by a flood of JDBC information, this month is characterized by J2EE patterns. Although only three articles on patterns made it through to the newsletter (the three that I felt had patterns relevant to performance), there were other patterns articles published. Looking out on the web, I see many sites dedicated to patterns, and the most interesting aspect is that the majority of them provide their examples in Java rather than other languages. This confirms to me that Java is the language of choice for serious software engineering.

To help maintain the patterns emphasis, the tips I've categorized this month are the analysis and design tips. If you look over on the tips page, you'll see three new categorized pages, All analysis & design tips, Design patterns and JDBC design tips.

Apart from those patterns articles, we're getting more articles on garbage collection and heap tuning every month (Kirk notes that the discussion groups are flagging this as important too). And the articles addressing synchronization issues are increasingly becoming ones that address generic shared resource problems. Those of us who have been doing OO programming in multi-user environments recognize these issues as ones we've struggled with for years. Where previously we had to look for information about this in newsgroups, vendor documentation, and obscure journals, now we're getting it all in freely accessible articles with examples in Java. Ah, the power of the web. I certainly feel like it makes me more productive, although I haven't got the metrics to prove it.

I also note that IBM have started a new tips section with short articles (articlets?) on specific Java tips. They aren't all performance specific tips, but this first month four out of five are. It's nice of IBM to work so hard to provide me with material for my website. One of the tips is the first I've listed on JNI (apart from multiple tips to "minimize your JNI calls").

Kirk follows the interesting discussions in the Java performance discussion groups. And we get the added bonus this month of finding out about the flying V, the skills of Eddie the Eagle, and the historic Flying Finn.

And here's my reminder to our Japanese readers that Yukio Andoh's translation will hopefully be available at http://www.hatena.org/JavaPerformanceTuning/ in a while.

News

Java performance tuning related news.

• Newly categorized Java performance tuning page giving all analysis & design tips
• Newly categorized Java performance tuning page giving Design patterns
• Newly categorized Java performance tuning page giving JDBC design tips
• Borland acquires VMGear (producer of OptimizeIt!) for $8 million. Will try to sell OptimizeIt! with JBuilder.
• IBM announces ECperf results for WebSphere.
• JavaParty, framework for moving a multithreaded application into multiple address space distributed environment. Includes optimized replacement for serialization (usable separately).
• The latest 1.4 Java SDK pre-release is available.
• Doug Lea proposes adding a java.util.concurrent package for common threading primitives such as: Atomic variables; Special-purpose locks, barriers, semaphores and condition variables; Queues and related collections designed for multithreaded use; Thread pools and custom execution frameworks. Three existing proprietary implementations are referenced.
• A Performance Evaluation of EJB with CORBA.
• An EJB design benchmark to optimize EJBs in different scenarios.
• The state of hardware acelerators for embedded devices.
• Interesting look at the options for speeding embedded Java.

Upcoming

• There should be a couple more category pages next month.
• I will continue extracting tips from more chapters of Wilson & Kesselman's book (sorry I ran out of time this month).
• Mastering EJB 2nd Edition has been released online (requires free registration). I'll try to extract the tips next month.

Books

• Windows 2000 Performance Guide. Chapter 5, "Multiprocessing" is available online at http://www.oreilly.com/catalog/w2kperf/chapter/ch05.html

Recent Articles

All the following page references have their tips extracted below.

• EJB design (JavaDevelopersJournal)
• Design Patterns (Sun)
• J2EE Design Patterns for the presentation tier (OnJava)
• Thread programming (DevX/JavaPro)
• Multithreading and read-write locks (EarthWeb)
• Multithreading and read-write locks, part 2 (EarthWeb)
• Expiring cached data (OnJava)
• Benchmarking (JavaDevelopersJournal)
• Hotspot garbage collection in detail (JavaWorld)
• Reference objects (JavaWorld)
• The Garbage Collector (IBM)
• Object management (IBM)
• JViewport scrolling performance (IBM)
• Using JNI Get* calls (IBM)
• Typesafe Enumeration gotchas (JavaWorld)
• Servlet 2.3 events (DevX/JavaPro)

Older Pages

All the following page references have their tips extracted below.

• Design patterns catalog (Sun)

Jack Shirazi

Kirk's roundup

At the end of the Christmas break, I did something that I hadn't done in quite some time. I watched a FIS K120 meter ski-jumping competition. For the uninitiated, ski jumpers glide down a ramp hurling themselves off the end after reaching speeds in excess of 90km/hr (55 m/hr). They then glide through the air for distances between 100-145 meters (110-160 yards). The skier must then execute a controlled telemark landing. A telemark landing requires that the skier keeps one foot just behind the other. Both knees are bent so that the skier looks as though he is preparing to kneel. A skier's score is the sum of two components, distance and style. Style points are awarded on in-run, take-off, flight, and landing. A proper take-off is the most technically challenging part of the jump. It must be just perfect for the skier to be able to position himself to generate the most lift. To understand just how much lift can be generated, we can look to the exploits of 'Eddie the Eagle' (former member of the UK Ski team). Eddie had no training nor experience when he decided to represent the UK in ski jumping. Lacking the necessary skills, training, coaching and equipment, poor Eddie finished dead last in every contest he competed in. He typically flew about 85 meters, or 30 meters less than most of the other competitors. Since Eddie's speed at the end of the ramp was about the same as the other competitors, the difference in distance can be attributed to his inability to generate lift.

In the traditional ski jumping style, the skies were held perfectly parallel in front of the body. The back and neck were perfectly flat with the skiers nose looking as though it's peering over the end of the skies. The skiers hand are held by his side in a prone position. Hand and arm (and even shoulder) movement, though not desirable, are used to stabilize the flight. In 1985, Jan Boklov introduced a new innovative technique. Ski jumping was never to be the same again.

At the time Matti Nykanen, known as the flying Finn, was the supreme ski jumper. Until he retired in 1988, he was practically unbeatable. In an attempt to gain a performance advantage over Nykanen, Jan Boklov developed a technique which we now call the flying V. To perform the flying V, during flight the skier hold the tips of their skis far apart so the skis form a V. Wind tunnel measurements demonstrated that using the flying V increased lift by as much as 28-percent. Further tests showed that the flight was far more stable. Jan Boklov could now jump farther than the flying Finn. The flights were so long that officials had to lower the starting position on the ramp because Jan (and others) would consistently fly past the K-point on the hill (a point of inflection on the hill after which it becomes increasingly more dangerous to land). But, the Swede still was not able to win because he was heavily penalized for style points. Part of the problem was that Boklov was unable to perform a telemark landing. He was also widely criticized and laughed at for abandoning the traditional jumping style. All of the changed by the 1988-89 season when he finally won the FIS World Cup tittle.

By then, other skiers, looking for that elusive competitive edge, were copying Boklov. By 1993, the flying V was used by every medal winner on the circuit. In the competition that I watched over the Christmas break, every skier used the flying V. To top it off, they were completing the jump with a classic telemark landing. So accolades to Jan Boklov whom, in defying convention, turned the ski jumping world on it's ear. His confidence in his new found technique allowed him to ride out all of the criticism until the establishment caught up with him. Lets see what inspiration and motivation we can find from the performance discussion groups.

The JavaRanch

Our first stop is at the Java Ranch. I must admit that I'm constantly amazed at how often the ugly duckling topic turns into a beautiful white swan. The most current example has to be a question concerning operators. The poster asked: does the i += k operator produce less byte code than i = i + k? Rather than having his question ignored, the Sheriff stepped in and answered that the byte code although different, was the same size. Now, there was a twist to this. He continued to say that the assembler code was also the same size! The next question is obvious. How did he get to see the assembler code? The Sheriff answered that he had put the code into an infinite loop. He then started the JVM (you must be using the JIT) in a C++ debugger. Since the code was in an infinite loop, the Sheriff claimed that it was easy to see the assembler code. I'm not sure where I might use this technique, but I certainly will put it into my tool box.

The next discussion centered around caching in a J2EE environment. There are several caching strategies that have been built into both application servers and products that function in that environment. In addition, one could write some custom caching as was suggested in the ensuing discussion. The easiest to tackle first is read-only data. That can be read into memory. Session or Entity beans could gain access to the data using a singleton pattern. One other technique that could be used to "pin" the table into memory is to bind it into the app servers JNDI context. For other ideas, check out http://www7.software.ibm.com/vad.nsf/data/document2361?OpenDocument&p=1

One final note. Of the many performance improvements in the JDK 1.4, we can add the method replaceAll() that has been added to String. Since Strings are my favorite performance bug-a-boo, I applaud this addition.

JavaGaming.org

Let's move on to www.javagaming.org as we follow the gamers quest for the perfect gaming experience. Now, I'm not sure why, but a poster was using a DataOutputStream to write out large arrays of float. He was trying to speed up this operation. The advice offered was to look to the new NIO package in the JDK 1.4. In the NIO package, the poster found the FloatBuffer and ByteBuffer classes. By reading in the data in byte chunks into a ByteBuffer, then converting the ByteBuffer into a FloatBuffer, the array of floats could be read in nearly 30 times faster than previously! The ByteBuffer to FloatBuffer conversion doesn't actually do anything other than put a new wrapper object on the underlying byte array. FloatBuffer reads the underlying array as an array of floats, so you can see why this procedure works faster - previously each float had to be read and written one at a time. The new procedure reads and writes the whole array of floats as one big byte array, which is as efficient as it gets.

In another note, there was a design question. The poster was working on a mult-user Java server. The server would need to execute in the order of five hundred different commands. In a wise decision, the poster decided not to use 500 if-then statements. Instead he decided to use reflection and then dispatch a message. But as is the case with every other gamer, he was very concerned with performance. In the chatter, it came out that a test had been run in both client and server mode. These modes, new to the JDK 1.4, have a direct effect on garbage collection that can cause significant performance differences. An early warning to us all that GC tuning is becoming an increasingly important topic.

The Server Side

The Server Side provided it's usual selection of quality postings and responses. Among these were a number of posts on ECperf. IBM has posted results at www.ecperf.theserverside.com.

In a post that demonstrates that not all performance bottlenecks occur in Java, we find a question regarding the configuration of Oracle. The poster starts by claiming that he is seeing different response times in two apparently identically configured Oracle installations. Although there is a bit of skepticism made about that claim, the response does provide some interesting information regarding Oracle transaction isolation levels and the sizing of TEMP tablespace. It was recommended to use READ_COMMIT as this would result in better response times than those offered by SERIALIZABLE. It was also stated that the sizing of TEMP tablespace should have no effect on performance.

In another posting, a hypothetical question is posed. How should one scale a system that is under increasing demand to perform a set of calculations? As the respondents pointed out, there are two strategies to handle this problem. One is distributed processing, the other is parallel computing. Each come with their own set of benefits and constraints. Once such constraint for distributed computing was that it might cost more to distribute the calculation than to actually perform it. There are other issues with distribution of requests that some hardware manufacture's are trying to address. Most of these rely on a symmetric view of your application. Thus, the suggestion of placing each service on it's own piece of hardware may not offer the best long term solution. Solutions for distributed computing is a fairly open ended topic. It's probably best that one look at their domain to find ways of constraining the solution space.

And that's it for this month's installment of the round-up. See you again next month when I'll discuss why there are so few takers for the ecperf, the J2EE benchmark.

Kirk Pepperdine.

Tips

http://www.sys-con.com/java/article.cfm?id=1268
EJB design (Page last updated January 2002, Added 2002-01-25, Author Boris Lublinsky). Tips:

• Some application server implementations (e.g., WebSphere) automatically convert remote communications to local communications to make them faster.
• Low granularity (i.e. fine-grained) methods in an EJB typically leads to poor performance of the overall system.
• Local interfaces in EJB 2.0 is one attempt to improve overall performance: local interfaces provide for beans in the same container to interact locally without involving RMI.
• The most effective way to improve the overall performance of EJB-based applications is to minimize the amount of method invocations, making the communications overhead negligible compared with the execution time. This can be achieved by implementing coarse-grained methods.
• Entity beans should not be simply mapped to database tables. Treating entity beans as such fine-grained objects which are effectively wrappers on table rows leads to increased network communications and heavier database communications than if entity beans are treated as coarse-grained components.
• For optimal performance, entity beans should be designed to: have large granularity, which usually means they should contain multiple Java classes and support multiple database tables; be associated with a certain amount of persistent data, typically multiple database tables, one of which should define the primary key for the whole bean; support meaningful business methods and encapsulate business rules to access the data.
• Don't use client transactions in the EJB environment since long-running transactions that can cause database lockup.
• Entity beans are transactional resources due to their stateful nature, but application server vendors often rely on the underlying database to lock and resolve access appropriately. Although this approach greatly improves performance, it provides the potential for database lockup.

http://developer.java.sun.com/developer/technicalArticles/J2EE/despat/
Design Patterns (Page last updated January 2002, Added 2002-01-25, Author Vijay Ramachandran). Tips:

• [Article discusses several design patterns: Model-View-Controller, Front Controller, Session Facade, Data Access Object].
• Use the Front Controller pattern to channel all client requests through a single decision point, which allows the application to be balanced at runtime.
• Use a Session Facade to provide a simple interface to a complex subsystem of enterprise beans, and to reduce network communication requirements.
• Use Data Access Objects to decouple the business logic from the data access logic, allowing data access optimizations to be decoupled from other types of optimizations.

http://www.onjava.com/pub/a/onjava/2002/01/16/patterns.html
J2EE Design Patterns for the presentation tier (Page last updated January 2002, Added 2002-01-25, Author Sue Spielman). Tips:

• [Article discusses several design patterns: Intercepting Filter, Front Controller, View Helper, Composite View, Service To Worker, Dispatch View. Performance is not explicitly covered, but at least a couple are relevant to getting good performance].

http://www.devx.com/upload/free/Features/Javapro/2002/02feb02/kr0202/kr0202-1.asp
Thread programming (Page last updated January 2002, Added 2002-01-25, Author Karthik Rangaraju). Tips:

• Use Djikstra semaphores (synchronized acquire()/release()) to control access to a finite pool of resources.
• Conditional events provide a more sophisticated version of the wait()/notify() mechanism which avoids some potential problems of that mechanism.
• Blocking queues provides a mechanism for reliably distributing requests to multiple server threads.
• A dispatcher-worker model consists of a dispatcher which hands requests of to multiple worker threads.
• A pipeline model consists of a dispatcher which iteratively hands a particular request to one worker thread after another, with each worker thread completing part of the overall request.

http://softwaredev.earthweb.com/java/article/0,,12082_951051,00.html
Multithreading and read-write locks (Page last updated January 2002, Added 2002-01-25, Author Nasir Khan). Tips:

• When a thread passes through a synchronized block, all variables throughout the thread are synchronized with main memory, not just the set of variables in the current method.

http://softwaredev.earthweb.com/java/article/0,,12082_951051,00.html
Multithreading and read-write locks, part 2 (Page last updated January 2002, Added 2002-01-25, Author Nasir Khan). Tips:

• Operations on primitive variables are atomic (except double and long), but a combination of two atomic operations is not atomic, and it is easy to make a mistake about this.
• Volatile variables are always synchronized with the main memory copy.

http://www.onjava.com/pub/a/onjava/2002/01/09/dataexp1.html
Expiring cached data (Page last updated January 2001, Added 2002-01-25, Author William Grosso). Tips:

• Caching data on the client can improve performance, reduce communication overheads and increase the scalability of an application.
• Be careful when caching information that cache doesn't contain out-of-date or incorrect information.
• Servlet sessions expire after a settable timeout, but screens that automatically refresh can keep a session alive indefinitely, even when the screen is no longer in use.
• Database connection pools can take one of two strategies: a limited size pool, where attempts to make connections beyond the pool size must wait for a connection to become idle; or a flexible sized pool with a preferred size which removes idle connections as soon as the preferred size is exceeded (i.e. temporarily able to exceed the preferred size). The fixed size pool is generally considered to be the better choice.
• A time-based expiration strategy is appropriate for most types of cache elements. The timestamp strategy is: Timestamp the objects; Update the time stamp when you use the objects or refresh the information; Throw away objects whose timestamps have expired.
• Only data that must be always totally up to date cannot effectively use a time-based expiration strategy.
• [Article implements a time-based expiration framework].

http://www.sys-con.com/java/article.cfm?id=1280
Benchmarking (Page last updated January 2002, Added 2002-01-25, Author Glenn Coates & Carl Barratt). Tips:

• A benchmark should exhaustively exercise the platform being tested and produce a numerical result corresponding to the speed of the benchmark.
• Benchmarks can be simplistic, made up of simple routines executed successively. Each routine should run for a reasonable amount of time.
• Ensure that performance statistics are not lost within start-up overheads.
• Don't rely on standard third-party benchmarks, as these may not apply to your application characteristics.
• Benchmarks could include looking at the speed of code execution; the response time of the user interface; implementation of the garbage collector; and memory issues.
• In J2ME, software accelerators may improve speed, but they may also consume excessive power compared to a processor that executes Java as its native language.
• No benchmark can replace the actual user application. At the earliest possible stage in the design process, application developers must run their own code on the proposed hardware.

http://www.javaworld.com/javaworld/jw-01-2002/jw-0111-hotspotgc.html
Hotspot garbage collection in detail (Page last updated January 2002, Added 2002-01-25, Author Ken Gottry). Tips:

• HotSpot garbage collection default parameters are effective for most small applications, but can be tuned to improve throughput for large, server-side applications.
• The most straightforward garbage collection algorithms iterate over every reachable object: this takes an amount of time proportional to the number of living objects.
• Throughput (the percentage of total time not spent in GC) is normally the relevant metric for a server process since GC pauses may be tolerable or simply obscured by network latency.
• Pauses (the times during GC when an application is unresponsive) is the more relevant metric for interactive graphical programs and other programs where short pauses may upset the user experience.
• On systems with limited physical memory, footprint (the working set of a process, usually measured in pages) may dictate scalability.
• [Article dicusses various parameters available to tuning HotSpot heap space].
• Use verbosegc to capture garnage collection statistics.

http://www.javaworld.com/javaworld/jw-01-2002/jw-0104-java101.html
Reference objects (Page last updated January 2002, Added 2002-01-25, Author Jeff Friesen). Tips:

• Cache objects such as images in memory for quicker presentation after the first display request.
• Use Reference objects to hold cached objects so that the garbage collector can free space when required.
• [Article discusses in detail the various Reference object types].

http://www-106.ibm.com/developerworks/java/library/j-jtctips/j-jtc0117b.html
The Garbage Collector (Page last updated January 2002, Added 2002-01-25, Author Phil Vickers). Tips:

• In most current JVMs (prior to 1.4) GC starts off by locking out all other threads in the JVM. GC is a stop-the-world, synchronous operation. Non-generationl GC requires scanning the stacks of every thread and the entire Java heap.
• Calling System.gc() explicitly is not good for performance, as it can be called when GC is not necessary, but will still result in a long pause of all JVM operations.

http://www-106.ibm.com/developerworks/java/library/j-jtctips/j-jtc0117e.html
Object management (Page last updated January 2002, Added 2002-01-25, Author Mark Bluemel). Tips:

• Avoid retaining objects accidentally, by holding references beyond an appropriate time for their release.
• Use profiling tools to identify unintentionally retained objects.
• Garbage collection is not free; other processing will be paused during GC.
• Try to reuse objects in preference to discarding and re-creating them.

http://www-106.ibm.com/developerworks/java/library/j-jtctips/j-jtc0117a.html
JViewport scrolling performance (Page last updated January 2002, Added 2002-01-25, Author Heather Brailsford). Tips:

• JViewport.BLIT_SCROLL_MODE is the default scrolling mode for JViewport in SDK 1.3 (available since 1.2.2). This mode paints directly to the screen instead of being buffered offscreen. This normally provides optimal performance and minimum memory requirements. However complex images may display some intermediate paint operations if the painting is not fast enough, giving jerky or flashing images. If this is unacceptable, try the alternate modes: setScrollMode(BACKINGSTORE_SCROLL_MODE) (intermediate performance, higher memory requirements); or setScrollMode(JViewport.SIMPLE_SCROLL_MODE) (slowest).

http://www-106.ibm.com/developerworks/java/library/j-jtctips/j-jtc0117d.html
Using JNI Get* calls (Page last updated January 2002, Added 2002-01-25, Author Mark Bluemel). Tips:

• If you use JNI Get* calls (for example, GetStringCritical), you must always use the corresponding Release* call (for example, ReleaseStringCritical) when you have finished with the data, even if the isCopy parameter indicates that no copy was taken.

http://www.javaworld.com/javaworld/javatips/jw-javatip122.html
Typesafe Enumeration gotchas (Page last updated January 2002, Added 2002-01-25, Author Vladimir Roubtsov). Tips:

• Implement readResolve() for Serializable Enumeration classes to maintain object identity.
• Ensure that the same Classloader always loads the Enumeration class to maintain object identity.

http://www.devx.com/upload/free/Features/Javapro/2002/02feb02/bk0202/bk0202-1.asp
Servlet 2.3 events (Page last updated January 2002, Added 2002-01-25, Author Budi Kurniawan). Tips:

• The Servlet 2.3 specification adds application and session events. [Event driven applications can often be scaled more easily than process driven applications].

http://java.sun.com/blueprints/patterns/j2ee_patterns/catalog.html
Design patterns catalog (Page last updated 2001, Added 2002-01-25, Author ?). Tips:

• [Page lists some patterns with summaries and links to detailed info. Patterns are: Data Access Object; Fast-Lane Reader; Front Controller; Page-by-Page Iterator; Session Facade; Value Object].
• Use the Data Access Object pattern to decouple business logic from data access logic, allowing for optimizations to be made in how data is managed.
• Use the Fast-Lane Reader pattern to accelerate read-only data access by not using enterprise beans.
• Use the Front Controller pattern to centralize incoming client requests, allowing optimizations to be made in aggregating the resulting view.
• Use the Page-by-Page Iterator pattern to efficiently access a large, remote list by retrieving its elements one sublist of value objects at a time.
• Use the Session Facade pattern to provide a unified, workflow-oriented interface to a set of enterprise beans, thus minimizing client calls to server EJBs.
• Use the Value Object pattern to efficiently transfer remote, fine-grained data by sending a coarse-grained view of the data.

Jack Shirazi