Gc:cms garbage collector One (English version)

Memory Management in the Java hotspot™virtual machine

Concurrent mark-sweep (CMS) Collector

For many applications, end-to-end throughput are not as important as fast response time. Young generation
Collections does not typically cause long pauses. However, old generation collections, though infrequent, can
Impose long pauses, especially when large heaps is involved. To address this issue, the HotSpot JVM includes a
Collector called the Concurrent Mark-sweep (CMS) collector, also known as the Low-latency collector.

Young Generation Collection Using the CMS Collector
The CMS collector collects the generation in the same manner as the parallel collector.
Old Generation Collection Using the CMS Collector
Most of the collection of the generation using the CMS collector are done concurrently with
The execution of the application.
A collection cycle for the CMS collector starts with a short pause, called theInitial Mark, that
Identifies the initial set of live objects directly reachable from the application code. Then,
During theConcurrent MarkingPhase, the collector marks all live objects that is transitively
Reachable from the this set. Because the application is running and updating reference
Marking phase is taking place, not all live objects was guaranteed to being marked at the end of the
Concurrent marking phase. To handle this, the application stops again for a second pause, calledRemark,
Which finalizes marking by revisiting all objects that were modified during the concurrent marking
Phase. Because The remark pause is more substantial than the initial mark, multiple threads was run in
Parallel to increase its efficiency.
At the end of the remark phase, all live objects in the heap is guaranteed to has been marked, so the
SubsequentConcurrent SweepPhase reclaims all the garbage it has been identified. Figure 7
Illustrates the differences between old generation collection using the serial Mark-sweep-compact
Collector and the CMS collector.

Since some tasks, such as revisiting objects during the remark phase, increase the amount of work the
Collector have to does, its overhead increases as well. This was a typical trade-off for most collectors that
Attempt to reduce pause times.
The CMS collector is the only collector, which is non-compacting. That's, after it frees the space that's was
occupied by dead objects, it does not move the live objects to one end of the old generation.

This saves time, but since the free space was not contiguous, the collector can no longer use a simple
Pointer indicating the next free location to which the next object can be allocated. Instead, it now
Needs to employ free lists. That is, it creates some number of lists linking together unallocated regions
of memory, and each time a object needs to is allocated, the appropriate list (based on the amount of
Memory needed) must be searched-a region large enough-to-hold the object as a result, allocations
Into the old generation is more expensive than they is with a simple bump-the-pointer technique.
This also imposes extra overhead to young generation collections, as most allocations in the old
Generation occur when objects is promoted during young generation collections.
Another disadvantage the CMS collector has are a requirement for larger heap sizes than the other
Collectors. Given that the application was allowed to run during the marking phase, it can continue to
Allocate memory, thereby potentially continuing to grow the old generation. Additionally, although the
Collector guarantees to identify all live objects during a marking phase, some objects may become
Garbage during that phase and they is not being reclaimed until the next old generation collection. Such
Objects is referred to asFloating Garbage.
Finally, fragmentation may occur due to lack of compaction. To deal with fragmentation, the CMS
Collector tracks popular object sizes, estimates future demand, and could split or join free blocks to
Meet demand.

Unlike the other collectors, the CMS collector does not the start a old generation collection when the old
Generation becomes full. Instead, it attempts to the start a collection early enough so the it can complete
Before that happens. Otherwise, the CMS collector reverts to the more time-consuming stop-the-world
Mark-sweep-compact algorithm used by the parallel and serial collectors. To avoid this, the CMS
Collector starts at a time based on statistics regarding previous collection times and what quickly the old
Generation becomes occupied. The CMS collector would also start a collection if the occupancy of the old
Generation exceeds something called the initiating occupancy. The value of the initiating occupancy is
Set by the command line Option–xx:cmsinitiatingoccupancyfraction=n, where N is a
Percentage of the old generation size. The default is 68.
In summary, compared to the parallel collector, the CMS collector decreases old generation pauses-
Sometimes dramatically-at the expense of slightly longer young generation pauses, some reduction in
throughput, and extra heap size requirements.
Incremental Mode
The CMS collector can be used in a mode in which the concurrent phases is done incrementally. This
Mode is meant to lessen the impact of a long concurrent phases by periodically stopping the concurrent
Phase to yield back processing to the application. The work did by the collector are divided into small
Chunks of time that is scheduled between young generation collections. This feature was useful when
Applications that need the low pause times provided by the concurrent collector is run on machines
With small numbers of processors (e.g., 1 or 2). For more information on usage of this mode, see the
"Tuning garbage Collection with the 5.0 java™virtual machine" paper referred into section 9.
When to use the CMS Collector
Use the CMS collector if your application needs shorter garbage collection pauses and can afford to
Share processor resources with the garbage collector when the application is running. (Due to its
concurrency, the CMS collector takes CPU cycles away from the application during a collection cycle.)
Typically, applications that has a relatively large set of long-lived data (a large old generation), and that
Run on machines with both or more processors, tend to benefit from the use of this collector. An example
would be Web servers. The CMS collector should is considered for any application with a low pause time
Requirement. It may also give good results-interactive applications with old generations of a modest
Size on a single processor.
CMS Collector Selection
If you want the CMS collector to being used, you must explicitly select it by specifying the command line
OPTION-XX:+USECONCMARKSWEEPGC. If you want it to be run in incremental mode, also enable that
Mode via The–xx:+cmsincrementalmode option.

Gc:cms garbage collector One (English version)