What you need to know about GC

What you need to know about
GC
Java SE 6 HotSpot™ VM
K e l u m S e n a n a y a k e

High Level Agenda
• Introduction
• Generations
• Collectors
• Other Considerations

Java is everywhere…
• Java™ Platform, Standard Edition (Java SE™) is
used for a wide variety of applications.
• JVM provides multiple garbage collectors,
each designed to satisfy different
requirements

Why memory?
• One strength of the J2SE platform is that it
shields the developer from the complexity of
memory allocation and garbage collection.
• However, once garbage collection is the
principal bottleneck, it is worth understanding
some aspects of this hidden implementation.

• When does the choice of a garbage collector
matter?
– For some applications, the answer is never
• Application can perform well in the presence of
garbage collection with pauses of modest frequency
and duration
– However, this is not the case for a large class of
applications

Garbage Collection… How?
• The most straightforward garbage collection
algorithms simply iterate over every reachable
object.
– The time this approach takes is proportional to
the number of live objects
• “Weak generational hypothesis”
– “most objects survive for only a short period of
time”

• Memory is managed in Generations
• Memory pools holding objects of different
ages

Performance Considerations
• Throughput
– is the percentage of total time not spent in
garbage collection, considered over long periods
of time
• Pauses
– are the times when an application appears
unresponsive because garbage collection is
occurring.
• A web server vs an interactive graphics
program

Performance…
• Footprint
– is the working set of a process, measured in pages and
cache lines
• Promptness
– is the time between when an object becomes dead
and when the memory becomes available
• In general, a particular generation sizing chooses
a trade-off between these considerations.

Performance…
• A very large young generation
– maximize throughput
– at the expense of footprint, promptness and
pause times.
• A small young generation
– young generation pauses can be minimized
– at the expense of throughput

Measurement
• -verbose:gc
information about the heap and garbage collection
to be printed at each collection.
[GC 325407K->83000K(776768K), 0.2300771 secs]
[GC 325816K->83372K(776768K), 0.2454258 secs]
[Full GC 267628K->83769K(776768K), 1.8479984 secs]

Measurement…
• -XX:+PrintGCDetails
[GC [DefNew: 64575K->959K(64576K), 0.0457646 secs]
196016K->133633K(261184K), 0.0459067 secs]
• -XX:+PrintGCTimeStamps
111.042: [GC 111.042: [DefNew: 8128K->8128K(8128K),
0.0000505 secs]111.042: [Tenured: 18154K->2311K(24576K),
0.1290354 secs] 26282K->2311K(32704K), 0.1293306 secs]

Sizing the Generations
• -Xms : initial sizes of the heap
• -Xmx : maximum sizes of the heap
• Collections occur when generations fill up
– Throughput is inversely proportional to the
amount of memory available

Sizing…
• By default, the virtual machine grows or
shrinks the heap at each collection to try to
keep the proportion of free space to live
objects at each collection within a specific
range
• -XX:MinHeapFreeRatio=<minimum>
• -XX:MaxHeapFreeRatio=<maximum>

Sizing…
MinHeapFreeRatio 40
MaxHeapFreeRatio 70
-Xms 3670k
-Xmx 64m
If the percent of free space in a generation falls below 40%, the generation will be
expanded to maintain 40% free space, up to the maximum allowed size of the
generation.
If the free space exceeds 70%, the generation will be contracted so that only 70% of
the space is free, subject to the minimum size of the generation.

The Young Generation
• The second most influential knob is the
proportion of the heap dedicated to the young
generation.
– The bigger the young generation, the less often
minor collections occur.
– Larger young generation implies a smaller tenured
generation (for a bounded heap size)
– will increase the frequency of major collections

• -XX:NewRatio : Defines the ratio between
the young and tenured generation
ex: -XX:NewRatio=3
• You can even decide the initial and max sizes
of the young space with parameters
NewSize and MaxNewSize

Survivor Space Sizing
• SurvivorRatio : can be used to tune the
size of the survivor spaces
• Sets the ratio between eden and a survivor
space
• This is often not as important for performance
• -XX:SurvivorRatio=6

• If survivor spaces are too small, copying
collection overflows directly into the tenured
generation.
• If survivor spaces are too large, they will be
uselessly empty.

The serial collector
• Uses a single thread to perform all garbage
collection work
– No communication overhead between threads
– Best-suited to single processor machines
– Multiprocessors for applications with small data
sets (up to approximately 100MB)
• -XX:+UseSerialGC

The parallel collector
• a.k.a throughput collector
• Performs minor collections in parallel
• Medium- to large-sized data sets that are run
on multiprocessor or multi-threaded
hardware.
• -XX:+UseParallelGC
• -XX:+UseParallelOldGC

Parallel collector…
• Select the parallel collector if,
– Peak application performance is the first priority
– There are no pause time requirements or pauses
of one second or longer are acceptable
• On a machine with N processors the parallel
collector uses N garbage collector threads
• -XX:ParallelGCThreads=<N>

• -XX:MaxGCPauseMillis=<N>
– a hint that pause times of <N> milliseconds or less
are desired
• -XX:GCTimeRatio=<N>
– Sets the ratio of garbage collection time to
application time to 1 / (1 + <N>)
– -XX:GCTimeRatio=19 sets a goal of 1/20 or
5% of the total time in garbage collection.

Generation Size Adjustments
• Growing and shrinking are done at different rates
• By default a generation grows in increments of
20% and shrinks in increments of 5%.
-XX:YoungGenerationSizeIncrement=<Y> for the
young generation
-XX:TenuredGenerationSizeIncrement=<T> for the
tenured generation
-XX:AdaptiveSizeDecrementScaleFactor=<D>
If the growth increment is X percent, the decrement for
shrinking is X / D percent

The Concurrent Collector
• Select concurrent collector If
– response time is more important than overall
throughput
– garbage collection pauses must be kept shorter than
approximately one second
• Suitable for
– applications which have a relatively large set of long-
lived data (a large tenured generation)
– run on machines with two or more processors
• -XX:+UseConcMarkSweepGC

Steps of Concurrent Collection
1. Stop all application threads and identify the set of objects
reachable from roots, then resume all application threads
2. Concurrently trace the reachable object graph, using one or more
processors, while the application threads are executing
3. Concurrently retrace sections of the object graph that were
modified since the tracing in the previous step, using one
processor
4. Stop all application threads and retrace sections of the roots and
object graph that may have been modified since they were last
examined, then resume all application threads
5. Concurrently sweep up the unreachable objects to the free lists
used for allocation, using one processor
6. Concurrently resize the heap and prepare the support data
structures for the next collection cycle, using one processor

Starting a Concurrent Collection Cycle
• Serial collector
– A major collection occurs whenever the tenured
generation becomes full
– all application threads are stopped while the
collection is done.
– stop-the-world condition
• concurrent collector
– starts at a time such that the collection can finish
before the tenured generation becomes full

Starting…
• Concurrent collector maintains dynamic
estimates based on recent history
• A concurrent collection will also start if the
occupancy of the tenured generation exceeds
an initiating occupancy
• -XX:CMSInitiatingOccupancyFraction=<N>
– <N> is an integral percentage (0-100) of the
tenured generation size.

Incremental Mode
• Normally, the concurrent collector uses one or
more processors during the entire concurrent
tracing phase, without voluntarily releasing them.
• Also, one processor is used for the entire
concurrent sweep phase, again without releasing
it.
• Incremental mode solves this problem by
breaking up the concurrent phases into short
bursts of activity, which are scheduled to occur
mid-way between minor pauses.

[GC [1 CMS-initial-mark: 13991K(20288K)] 14103K(22400K), 0.0023781 secs]
[GC [DefNew: 2112K->64K(2112K), 0.0837052 secs] 16103K->15476K(22400K), 0.0838519
secs]
...
secs]
[CMS-concurrent-mark: 0.267/0.374 secs]
secs]
[CMS-concurrent-preclean: 0.044/0.064 secs]
[GC [1 CMS-remark: 16090K(20288K)] 17242K(22400K), 0.0210460 secs]
secs]
secs]
...
[GC [DefNew: 2111K->0K(2112K), 0.0035190 secs] 17527K->15479K(22400K), 0.0036052 secs]
[CMS-concurrent-sweep: 0.291/0.662 secs]
[CMS-concurrent-reset: 0.016/0.016 secs]

Incremental Mode…
• Recommended Options
– To use i-cms in Java SE 6, use the following
command line options:
-XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode

Excessive GC Time and OutOfMemoryError
• Parallel collector and concurrent collectore will
throw an OutOfMemoryError if too much time is
being spent in garbage collection
– If more than 98% of the total time is spent in garbage
collection and less than 2% of the heap is recovered
– Prevents applications from running for an extended
period of time while making little or no progress
• -XX:-UseGCOverheadLimit
– To disable this feature

Permanent Generation Size
• The permanent generation does not have a
noticeable impact on GC performance
• However, some applications dynamically
generate and load many classes; for example,
some implementations of JavaServer Pages
(JSP) pages.
• -XX:MaxPermSize=<N>

The size of the JVM thread stack
• When Java creates a new thread, it pre-
allocates a fixed-size block of memory for that
thread's stack.
• If you have lots of threads - the memory
saving is the reduction in stack size times the
number of threads.
– May increase the chance of a Stack Overflow error
• On x86 Solaris/Linux it is 320k in the 32-bit
VM and 1024k in the 64-bit VM

JVM thread stack…
• (total RAM used by JVM process) = (heap size)
+ (number of threads)x(thread stack size)
• If application has a lot of threads might be
running out of memory
• You can reduce your stack size by running with
the -Xss option
• Ex : -Xss64k

References
[1] "Java SE 6 HotSpot™ Virtual Machine Garbage
Collection Tuning", [Online]. Available:
http://www.oracle.com/technetwork/java/javase/g
c-tuning-6-140523.html [Accessed 12-May-2014]
[2] "Frequently Asked Questions About the Java
HotSpot VM", [Online]. Available:
http://www.oracle.com/technetwork/java/hotspotf
aq-138619.htm [Accessed 12-May-2014]

What you need to know about GC

Recommended

More Related Content

What's hot (12)

Viewers also liked (20)

Similar to What you need to know about GC (20)

Recently uploaded (20)

What you need to know about GC