The default collector for Java server class machines will optimize for throughput but be tolerant of somewhat long pause times. If you would prefer to have minimal pause times at the expense of some throughput and increased CPU usage, consider using the CMS collector.

To use the CMS collector

Follow this procedure.

Use the jvmstat utility to monitor HotSpot garbage collection. (See Further Information.)

For detailed information on tuning the garbage collector, see Java SE 6 HotSpot Virtual Machine Garbage Collection Tuning (http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html).

For applications that do not dynamically generate and load classes, the size of the permanent generation does not affect GC performance. For applications that dynamically generate and load classes (for example, JSP applications), the size of the permanent generation does affect GC performance, since filling the permanent generation can trigger a Full GC. Tune the maximum permanent generation with the -XX:MaxPermSize option.

Although applications can explicitly invoke GC with the System.gc() method, doing so is a bad idea since this forces major collections, and inhibits scalability on large systems. It is best to disable explicit GC by using the flag -XX:+DisableExplicitGC.

GlassFish Server uses RMI in the Administration module for monitoring. Garbage cannot be collected in RMI-based distributed applications without occasional local collections, so RMI forces a periodic full collection. Control the frequency of these collections with the property -sun.rmi.dgc.client.gcInterval. For example, - java -Dsun.rmi.dgc.client.gcInterval=3600000 specifies explicit collection once per hour instead of the default rate of once per minute.

Maximum heap size depends on maximum address space per process. The following table shows the maximum per-process address values for various platforms:

Table 4-1 Maximum Address Space Per Process

Maximum heap space is always smaller than maximum address space per process, because the process also needs space for stack, libraries, and so on. To determine the maximum heap space that can be allocated, use a profiling tool to examine the way memory is used. Gauge the maximum stack space the process uses and the amount of memory taken up libraries and other memory structures. The difference between the maximum address space and the total of those values is the amount of memory that can be allocated to the heap.

You can improve performance by increasing your heap size or using a different garbage collector. In general, for long-running server applications, use the Java SE throughput collector on machines with multiple processors (-XX:+AggressiveHeap) and as large a heap as you can fit in the free memory of your machine.

You can control the heap size with the following JVM parameters:

The -Xms and -Xmx parameters define the minimum and maximum heap sizes, respectively. Since GC occurs when the generations fill up, throughput is inversely proportional to the amount of the memory available. By default, the JVM grows or shrinks the heap at each GC to try to keep the proportion of free space to the living objects at each collection within a specific range. This range is set as a percentage by the parameters -XX:MinHeapFreeRatio=`minimum and `-XX:MaxHeapFreeRatio=`maximum; and the total size bounded by `-Xms and -Xmx.

Set the values of -Xms and -Xmx equal to each other for a fixed heap size. When the heap grows or shrinks, the JVM must recalculate the old and new generation sizes to maintain a predefined NewRatio.

The NewSize and MaxNewSize parameters control the new generation’s minimum and maximum size. Regulate the new generation size by setting these parameters equal. The bigger the younger generation, the less often minor collections occur. The size of the young generation relative to the old generation is controlled by NewRatio. For example, setting -XX:NewRatio=3 means that the ratio between the old and young generation is 1:3, the combined size of eden and the survivor spaces will be fourth of the heap.

By default, the GlassFish Server is invoked with the Java HotSpot Server JVM. The default NewRatio for the Server JVM is 2: the old generation occupies 2/3 of the heap while the new generation occupies 1/3. The larger new generation can accommodate many more short-lived objects, decreasing the need for slow major collections. The old generation is still sufficiently large enough to hold many long-lived objects.

To size the Java heap:

For up-to-date defaults, see Java HotSpot VM Options (http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html).

Example 4-1 Heap Configuration on Solaris

This is an exmple heap configuration used by GlassFish Server on Solaris for large applications:

Survivor Ratio Sizing

The SurvivorRatio parameter controls the size of the two survivor spaces. For example, -XX:SurvivorRatio=6 sets the ratio between each survivor space and eden to be 1:6, each survivor space will be one eighth of the young generation. The default for Solaris is 32. If survivor spaces are too small, copying collection overflows directly into the old generation. If survivor spaces are too large, they will be empty. At each GC, the JVM determines the number of times an object can be copied before it is tenured, called the tenure threshold. This threshold is chosen to keep the survivor space half full.

Use the option -XX:+PrintTenuringDistribution to show the threshold and ages of the objects in the new generation. It is useful for observing the lifetime distribution of an application.

Before You Begin

To perform rebasing, you need:

Example 4-2 Heap Configuration on Windows

This is an example heap configuration used by Oracle GlassFish Server for heavy server-centric applications, on Windows, as set in the domain.xml file.

See Also

For more information on rebasing, see MSDN documentation for rebase utility (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tools/tools/rebase.asp).