Java technology, IBM Style: Garbage collection Strategy, part 1th: Different strategies provide flexibility

You can configure the garbage collection (GC) in IBM Developer Kit for the Java 5.0 Platform (IBM SDK) using 4 different policies. This article (the first of two articles on GC) introduces different garbage collection strategies and discusses their nature. Before reading this article, you should have a basic understanding of garbage collection in the Java platform. The 2nd part will give a quantitative approach to the selection strategy, as well as some examples.

Why should there be different GC policies?

The ability to use different policies enables developers to increase their control over the application. There are many kinds of GC algorithms, each of which has advantages and disadvantages, depending on the type of workload. (If you are unfamiliar with the general subject of the GC algorithm, see the links to other readings in resources.) In IBM SDK 5.0, garbage collection can be configured with one of 4 strategies, each using its own algorithm. The default policy is sufficient for most applications. If there is no particular requirement for the performance of your application, you may not be interested in the content of this article (and the next article), and you can run IBM SDK 5.0 without changing the GC policy. However, if your application requires optimal performance, or if you are concerned about the length of the GC pause time, read on. You will see that the latest version offers more choices than previous versions.

So why not let the IBM implementation of the Java runtime automatically make a choice for you? Because it's not always possible. It's difficult to understand your needs at run time. In some cases, you want the application to have a high throughput, and in other cases you want to reduce the pause time.

Table 1 lists the available policies and explains when each strategy should be used. The following sections describe in detail the nature of each strategy.

policy	options
	-xgcpolicy:optthruput (optional	Default policy. This strategy is commonly used for applications that have more significant throughput than a short-lived GC pause. The application pauses every time a garbage collection is made.
	-xgcpol The Icy:optavgpause
"	-xgcpolicy:ge Ncon
"	-XGCPOLICY:SUBP Ool

Definitions of some terms

Throughput is the amount of data processed by the application. The metrics for measuring throughput are related to specific applications.

The pause time is the time the garbage collector has to stop all application threads to collect the heap.

In this article, use the abbreviations in the command-line options in table 1 to represent these policies: Optthruput represents optimizations for throughput, Optavgpause represents optimizations for downtime, GENCON represents generational concurrency, and subpool represents a child pool.

When should you consider a non-default GC policy?

It is recommended that you always use the default GC policy first. Before discarding the default policy, you need to know under what circumstances other policies should be adopted. Table 2 shows some of the reasons:

Switch to	Reason
Optavgpause	My application cannot tolerate such a long GC pause time. If the GC pause time can be reduced, some of the performance degradation is acceptable. My application is running on a 64-bit platform and using a very large heap--more than 3 or 4GB. My application is a GUI application and I am very concerned about the user response time.
Gencon	My application allocates a lot of short-term surviving objects. Heap space appears fragmented. My application is transactional (that is, objects in a transaction no longer exist after the transaction is committed).
Subpool	On large multiprocessor computers, I encountered scalability issues.