Home | Business News | Browse by Publication | J | Java Developer's Journal

Avoid bothersome: garbage collection pauses: use Java in mission-critical display systems. (J2SE).

Article Excerpt
Many engineers complain that the non-deterministic behavior of the garbage collector prevents them from utilizing the Java environment for mission-critical applications, especially distributed message-driven displays (GUIs) where user responsiveness is critical. We agree that garbage collection does occur at the worst times: for example, when a user clicks a mouse or a new message enters the system requiring immediate processing. These events must be handled without the delay of in-progress garbage collection. How do we prevent these garbage collection pauses that interfere with the responsiveness of an application ("bothersome pauses")?

We have discovered a very effective technique to prevent bothersome garbage collection pauses and build responsive Java applications. This technique or pattern is especially effective for a distributive message-driven display system with soft real-time constraints. This article details this pattern in three simple steps and provides evidence of the effectiveness of the technique.

Pattern to Control Garbage Collection Pauses

The Java environment provides so many benefits to the software community--platform independence, industry momentum, a plethora of resources (online tutorials, code, interest groups, etc.), object-oriented utilities and interfaces (collections, network I/O, Swing display, etc.) that can be plugged in and out--that once you have experienced working with Java it's hard to go back to traditional languages. Unfortunately, in some mission-critical applications, like message-driven GUIs that must be very responsive to user events, the requirements force you to take that step backward. There's no room for multiple second garbage collection pauses. (The garbage collector collects all the "unreachable" references in an application so the space consumed by them can be reused. It's a low-priority thread that usually only takes priority over other threads when the VM is running out of memory.) Do we really have to lose all the benefits of Java? First, let's consider the requirements.

A system engineer should consider imposing requirements for garbage collection like the following list taken from a telecom industry example (see References).

1. GC sequential overhead on a system may not be more than 10% to ensure scalability and optimal use of system resources for maximum throughput.

2. Any single GC pause during the entire application run may be no more than 200ms to meet the latency requirements as set by the protocol between the client and the server, and to ensure good response times by the server.

Armed with these requirements, the system engineer has defined the worst-case behavior in a manner that can be tested.

The next question is: How do we meet these requirements? Alka Gupta and Michael Doyle make excellent suggestions in their article (see References). Their approach is to tune the parameters on the Java Virtual Machine (JVM). We take a slightly different approach that leaves the use of parameter definitions as defined by the JVM to be used as a final tuning technique.

Why not tell the garbage collector what and when to collect?

In other words, control garbage collection via the software architecture. Make the job of the garbage collector easy! This technique can be described as a multiple step pattern. The first step of the pattern is described below as "Nullify Objects." The second step involves forcing garbage collection to occur as delineated in "Forcing Garbage Collection." The final step involves either placing persistent data out of the reach of the collector or into a data...