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.
gotcha