Option 1: Use the default throughput/parallel scavenge collector
with built-in tuning enabled.Starting with Version 5, the Sun HotSPot
JVM provides some detection of the operating system on which the server
is running, and the JVM attempts to set up an appropriate generational
garbage collection mode, that is either parallel or serial, depending
on the presence of multiple processors, and the size of physical memory.
It is expected that all of the hardware, on which the product runs
in production and preproduction mode, satisfies the requirements to
be considered a server class machine. However, some development hardware
might not meet this criteria.
The behavior of the throughput
garbage collector, whether tuned automatically or not, remains the
same and introduces some significant pauses, that are proportional
to the size of the used heap, into execution of the Java application system as it tries to maximize the benefit of generational
garbage collection. However, these automatic algorithms cannot determine
if your workload well-suits its actions, or whether the system requires
or is better suited to a different garbage collection strategy.
Consult these tuning parameters:
- -XX:+UseParallelGC
- -XX:+UseAdaptiveSizePolicy
- -XX:+AggressiveHeap
Option 3: Use the concurrent low-pause mark-sweep collectorThis collector is a radical departure from the evolution of generational
garbage collection that has under pinned the Hotspot architecture,
permitting the overlap of application thread processing with a dedicated
low-priority, background garbage collection thread. If your application
data is incompatible with the behavior of the default throughput collector,
then the concurrent mark-sweep (CMS) collector might be a viable strategy,
particularly for application systems that are intolerant of invasive
pauses. This collector is particularly helpful with the very large
heaps that are used with the 64-bit JVM, or applications that have
a large set of long-lived data, also referred to as a large tenured
generation, and that maintains comparatively good cache utilization,
largely preserving pages of the young generation, even while the background
thread must scan through all the pages of the entire heap.
To
employ the concurrent mark-sweep collector as the principle housekeeping
agent, add this option, instead of any other garbage collection modes,
to your JVM configuration.
Consult these tuning parameters:
- -XX:+UseConcMarkSweepGC
- -XX:CMSInitiatingOccupancyFraction=75
- -XX:SurvivorRatio=6
- -XX:MaxTenuringThreshold=8
- -XX:NewSize=128m
Among the difficulties for tuning with CMS, is that the worst
case garbage collection times, which is when the CMS cycle aborts,
can take last several seconds, which is especially costly for a system
that uses CMS precisely to avoid long pauses. Consequently, service
level agreements might dictate the use of CMS, because the average
or median pause times are very, very low, and the tuning must err
on the cautious side to ensure that CMS cycles don't abort. CMS succeeds
only when its anticipatory trigger ensures that the CMS cycle always
starts early enough to ensure sufficient free resources are available
before they are demanded. If the CMS collector is unable to finish
before the tenured generation fills up, the collection is completed
by pausing the application threads, which is known as a full collection.
Full collections are a sign that further tuning is required to the
CMS collector to make it better suit your application.
Finally,
unlike other garbage collection modes with a compaction phase, the
use of CMS theoretically raises the risk of fragmentation occurring
with the HotSpot. However, in practice this is rarely a problem while
the collection recovers a healthy proportion of the heap. In cases
when the CMS fails, or aborts a collection, an alternative compacting
garbage collection is triggered. Inevitably any other type of garbage
collection incurs a significant invasive pause compared to a normal
CMS collection.
Avoid trouble: As with the
throughput collector, there are considerably more options available
for explicitly controlling CMS. However, those mentioned represent
the core of the options that you are likely to need to considered
using when you are tuning the HotSpot JVM.