IBM Software Group
Java Garbage Collection
Best Practices for Sizing and Tuning the Java Heap
Chris Bailey
WebSphere Support Technical Exchange
IBM Software Group
Objectives
Overview
Selecting the Correct GC Policy
Sizing the Java heap
Questions/Answers
WebSphere Support Technical Exchange
IBM Software Group
Garbage Collection Performance
GC performance issues can take many forms
Definition of a performance problem is user centric
User requirement may be for:
Very short GC pause times
Maximum throughput
A balance of both
First step is ensure that the correct GC policy has been selected for
the workload type
Helpful to have an understanding of GC mechanisms
Second step is to ensure heap sizing is correct
Third step us to look for specific performance issues
WebSphere Support Technical Exchange
IBM Software Group
Selecting the Correct GC Policy
WebSphere Support Technical Exchange
IBM Software Group
Understanding Garbage Collection
Responsible for allocation and freeing of:
Java objects, Array objects and Java classes
Allocates objects using a contiguous section of Java heap
Ensures the object remains as long as it is in use or live
Determination based on a reference from another live object or
from outside of the Heap
Reclaims objects that are no longer referenced
Ensures that any finalize method is run before the object is
reclaimed
WebSphere Support Technical Exchange
IBM Software Group
Object Allocation
Requires a contiguous area of Java heap
Driven by requests from:
The Java application
JNI code
Most allocations take place in Thread Local Heaps (TLHs)
Threads reserve a chunk of free heap to allocate from
Reduces contention on allocation lock
Keeps code running in a straight line (fewer failures)
Meant to be fast
Available for objects < 512 bytes in size
Larger allocates take place under a global heap lock
These allocations are one time costs out of line allocate
Multiple threads allocating larger objects at the same time will
contend
WebSphere Support Technical Exchange
IBM Software Group
Object Reclamation (Garbage Collection)
Occurs under two scenarios:
An allocation failure
An object allocation is requested and not enough contiguous memory is available
A programmatically requested garbage collection cycle
call is made to System.GC() or Runtime.GC()
the Distributed Garbage Collector is running
call to JVMPI/TI is made
Two main technologies used to remove the garbage:
Mark Sweep Collector
Copy Collector
IBM uses a mark sweep collector
or a combination for generational
WebSphere Support Technical Exchange
IBM Software Group
Global Collection Policies
Garbage Collection can be broken down into 2 (3) steps
Mark:
Find all live objects in the system
Sweep:
Reclaim unused heap memory to the free list
Compact:
Reduce fragmentation within the free list
All steps are in a single stop-the-world (STW) phase
Application pauses whilst garbage collection is done
Each step is performed as a parallel task within itself
Four GC Policies, optimized for different scenarios
-Xgcpolicy:optthruput
-Xgcpolicy:optavgpause
-Xgcpolicy:gencon
-Xgcpolicy:subpools
WebSphere Support Technical Exchange
optimized for batch type applications
optimized for applications with responsiveness
criteria
optimized for highly transactional workloads
optimized for large systems with allocation
contention
IBM Software Group
Parallel GC (optthruput)
Parallel Mark Sweep Collector, with compaction avoidance
Created to make use of additional processors on server systems
Designed to increase performance for SMP and not degrade
performance for uni-processor systems
Optimized for Throughput
Best policy for batch type applications
Consists of a single flat Java heap:
0 GB
2 GB
LOA
Heap Base
WebSphere Support Technical Exchange
Heap Size
Heap Limit
IBM Software Group
GC Helper Threads
Parallelism achieved through the use of GC Helper Threads
Parked set of threads that wake to share GC work
Main GC thread generates the root set of objects
Helper threads share the work for the rest of the phases
Number of helpers is one less than the number of processing
units
So helper threads and main GC thread equals the number of
processing units
Configurable using -Xgcthreads
WebSphere Support Technical Exchange
10
IBM Software Group
Parallel Mark/Parallel Sweep view of GC
WebSphere Support Technical Exchange
11
IBM Software Group
Concurrent GC (optavgpause)
Reduces and makes more consistent the time spent inside Stop the
World GC
Reduction usually between 90 and 95%
Achieved by carrying out some of the STW work whilst application is
running
1.4.2:
Concurrent Marking
5.0:
Concurrent Marking and Concurrent Sweeping
Slight overhead on thruput for greatly reduced STW times
Policy is ideal for systems with responsiveness criteria
eg. Portal applications
WebSphere Support Technical Exchange
12
IBM Software Group
Parallel and Concurrent Mark/Sweep
Concurrent Kickoff
WebSphere Support Technical Exchange
13
IBM Software Group
Concurrent Mark hidden object issue
Higher heap usage
WebSphere Support Technical Exchange
14
IBM Software Group
Concurrent Mark hidden object issue
Higher heap usage
Dangling pointer!
because not all garbage removed
WebSphere Support Technical Exchange
15
IBM Software Group
Generational and Concurrent GC (gencon)
Similar in concept to that used by Sun and HP
Parallel copy and concurrent global collects by default
Motivation: Objects die young so focus collection efforts on
recently created objects
Divide the heap up into a two areas: new and old
Perform allocates from the new area
Collections focus on the new area
Objects that survive a number of collects in new area are
promoted to old area (tenured)
2 GB
0 GB
Allocate
Survivor
Nursery (new) Space
Heap Base
LOA
Tenured (old) Space
Heap Size
Heap Limit
Ideal for transactional and high data throughput workloads
WebSphere Support Technical Exchange
16
IBM Software Group
Nursery (new) Space Copy Collection
Nursery/Young Generation
Allocate Space
Survivor
Space
Survivor
Allocate Space
Space
Nursery is split into two spaces (semi-spaces)
Only one contains live objects and is available for allocation
Minor collections (Scavenges) move objects between spaces
Role of spaces is reversed
Movement results in implicit compaction
WebSphere Support Technical Exchange
17
IBM Software Group
Subpooling (subpool)
Goals:
Reduce allocation lock contention by distributing free memory into
multiple lists
Reduce allocation contention through use of atomic operations instead of
a heap lock
Prevent premature garbage collections by using a best fit (or closer to
best fit) policy instead of address ordered
Ideal for very large SMP systems where large amounts data is being
allocated
where there is heap lock contention
WebSphere Support Technical Exchange
18
IBM Software Group
Looking for Heap Lock Contention
All locks can be profiled using Java Lock Analyzer (JLA)
http://www.alphaworks.ibm.com/tech/jla
(AlphaWorks)
Provides time accounting and contention statistics for
Java and JVM locks
Functionality includes:
Counters associated with contended locks
Total number of successful acquires
Recursive acquires times a thread acquires a lock it
already owns
Number of times a thread blocks because a monitor is
already owned
Cumulative time the monitor was held.
WebSphere Support Technical Exchange
19
IBM Software Group
JLA Sample Report
System (Registered) Monitors
%MISS
87
9
5
0
0
0
0
0
0
0
0
0
0
0
GETS NONREC
5273
5273
6870
6869
1123
1123
1153
1147
46149 45877
33734 23483
5
5
5
5
5
5
1
1
0
0
0
0
0
0
0
0
SLOW
4572
631
51
5
134
19
0
0
0
0
0
0
0
0
REC TIER2 TIER3 %UTIL AVER-HTM MON-NAME
0 710708 18487
1
95408 JITC Global_Compile lock
1 113420 2976
0
11807 Heap lock
0 11098
286
1
248385 Binclass lock
6
1307
33
0
47974 Monitor Cache lock
272 36961
877
1
6558 JITC CHA lock
10251
6544
150
1
17083 Thread queue lock
0
0
0
0 9309689 JNI Global Reference lock
0
0
0
0 9283000 JNI Pinning lock
0
0
0
0 9442968 Sleep lock
0
0
0
0
0 Monitor Registry lock
0
0
0
0
0 Evacuation Region lock
0
0
0
0
0 Method trace lock
0
0
0
0
0 Classloader lock
0
0
0
0
0 Heap Promotion lock
Java (Inflated) Monitors
%MISS
15
2
0
GETS NONREC
68
68
42
42
70
70
SLOW
10
1
0
REC TIER2 TIER3 %UTIL AVER-HTM
0
2204
56
2 11936405
0
186
5
0
300478
0
41
1
0
7617
WebSphere Support Technical Exchange
MON-NAME
test.lock.testlock1@A09410/A09418
test.lock.testlock2@D31358/D31360
java.lang.ref.ReferenceQueue$Lock@920628/920630
20
IBM Software Group
JLA: Fields in the report
WebSphere Support Technical Exchange
21
IBM Software Group
Choosing the Right GC Policy
Four GC Policies, optimized for different scenarios
-Xgcpolicy:optthruput
optimized for batch type applications
-Xgcpolicy:optavgpause optimized for applications with
responsiveness criteria
-Xgcpolicy:gencon
optimized for highly transactional
workloads
-Xgcpolicy:subpools
optimized for large systems with allocation
contention
How do I know whether to use optavgpause or gencon?
Monitor GC activity
Look for certain characteristics
WebSphere Support Technical Exchange
22
IBM Software Group
Monitoring GC Activity
Use of Verbose GC logging
only data that is required for GC performance tuning
Graph Verbose GC output using GC and Memory Visualizer (GCMV) from ISA
Activated using command line options
-verbose:gc
-Xverbosegclog:[DIR_PATH][FILE_NAME],X,Y
where:
[DIR_PATH] is the directory where the file should be written
[FILE_NAME]
is the name of the file to write the logging to
X
is the number of files to
Y
is the number of GC cycles a file should contain
Performance Cost:
(very) basic testing shows a 2% overhead for GC duration of 200ms
eg. if application GC overhead is 5%, it would become 5.1%
WebSphere Support Technical Exchange
23
IBM Software Group
Important Characteristics for Choosing GC Policy
Rate of Garbage Collection
High rates of object burn point to large numbers of transitional objects, and
therefore the application may well benefit from the use of gencon
Large Object Allocations?
The allocation of very large objects adversely affects gencon unless the nursery is
sufficiently large enough. The application may well benefit from optavgpuse
Large heap usage variations
The optavgpause algorithms are best suited to consistent allocation profiles
Where large variations occur, gencon may be better suited
Rule of thumb: if GC overhead is > 10%, youve most likely chosen the wrong one
WebSphere Support Technical Exchange
24
IBM Software Group
Rate of Garbage Collection
optavgpause
gencon
Gencon could handle a higher rate of garbage collection
Completing the test quicker
Gencon had a smaller percentage of time in garbage collection
Gencon had a shorter maximum pause time
WebSphere Support Technical Exchange
25
IBM Software Group
Rate of Garbage Collection
Gencon provides less frequent long Garbage Collection cycles
Gencon provides a shorter longest Garbage Collection cycle
WebSphere Support Technical Exchange
26
IBM Software Group
Large Object Allocations
(Very) Large Object allocations affects the gencon GC policy
If object is larger than the Nursery size, the object is immediately tenured
Removes the benefit of generational heaps
Still has the additional overhead of running generational
If object is fits in the nursery but fills it, frequent nursery collects will have to occur
Too frequent nursery collects mean objects are likely to survive and need copying
Copying is an expensive process
If (Very) Large Objects are being used, a sufficiently large enough nursery is required
WebSphere Support Technical Exchange
27
IBM Software Group
Sizing the Java Heap
WebSphere Support Technical Exchange
IBM Software Group
Sizing the Java Heap
Maximum possible Java heap sizes
The correct Java heap size
Fixed heap sizes vs. Variable heap sizes
Heap Sizing for Generational GC
WebSphere Support Technical Exchange
29
IBM Software Group
Maximum Possible Heap Size
32 bit Java processes have maximum possible heap size
Varies according to the OS and platform used
Determined by the process memory layout
64 bit processes do not have this limit
Limit exists, but is so large it can be effectively ignored
Addressability usually between 2^44 and 2^64
Which is 16+ TeraBytes
WebSphere Support Technical Exchange
30
IBM Software Group
Java Process Memory Layout
An Operating System process like any other application:
Subject to OS and architecture restrictions
32bit architecture has an addressable range of:
0 GB
0x0
2^32 which is 0x00000000 0xFFFFFFFF
which is 4GB
2 GB
1 GB
0x40000000
0x80000000
3 GB
0xC0000000
4 GB
0xFFFFFFFF
Not all addressable space is available to the application
The operating system needs memory for:
The kernel
The runtime support libraries
Varies according to Operating System
How much memory is needed and where that memory is located
WebSphere Support Technical Exchange
31
IBM Software Group
Memory Available to the Java Process
On Windows:
0 GB
1 GB
2 GB
4 GB
3 GB
Operating System Space
0x40000000
0x0
0x80000000
0xC0000000
Libraries
0xFFFFFFFF
On AIX:
0 GB
1 GB
2 GB
Kernel
0x0
4 GB
3 GB
Libraries
0x40000000
WebSphere Support Technical Exchange
0x80000000
0xC0000000
0xFFFFFFFF
32
IBM Software Group
Java Process Restrictions
Not all Java Process space is available to the Java application
The Java Runtime needs memory for:
The Java Virtual Machine
Backing resources for some Java objects
This memory area as well as some other allocations, is part of the
Native Heap
Memory not allocated to the Java Heap is available to the native heap
Available memory space Java heap = native
heap
Effectively, the Java process maintains two memory pools
WebSphere Support Technical Exchange
33
IBM Software Group
The Native Heap
Allocated using malloc() and therefore subject to memory
management by the OS
Used for Virtual Machine resources, eg:
Execution engine
Class Loader
Garbage Collector infrastructure
Used to underpin Java objects:
Threads, Classes, AWT objects, ZipFiles
Used for allocations by JNI code
WebSphere Support Technical Exchange
34
IBM Software Group
Native Heap available to Application
On Windows
0 GB
2 GB
1 GB
Java Heap
Native Heap
0x40000000
0x0
VM Resources
4 GB
3 GB
Operating System Space
0x80000000
0xC0000000
Libraries
0xFFFFFFFF
On AIX (1.4.2 with small heaps)
0 GB
Kernel
0x0
2 GB
1 GB
Native Heap
Java Heap
0x40000000
0x80000000
4 GB
3 GB
Libraries
0xC0000000
0xFFFFFFFF
VM Resources
WebSphere Support Technical Exchange
35
IBM Software Group
Layout with Large Java Heaps on AIX
Applies to heaps > 1GB in size and Java 5.0
Java heap becomes allocated using mmap()
Segments used start at 0xC and work downwards
understanding memory layout important for monitoring
0 GB
0x3
Kernel
0x0
1 GB
2 GB
0x7
Native Heap
0x40000000
3 GB
4 GB
0xD
Java Heap
0x80000000
Libraries
0xC0000000
0xFFFFFFFF
VM Resources
WebSphere Support Technical Exchange
36
IBM Software Group
Memory Layout for Linux
Linux:
0 GB
1 GB
4 GB
3 GB
Native Heap
Java Heap
0x40000000
0x0
2 GB
VM Resources
0x80000000
TASK_SIZE
Kernel
0xC0000000
0xFFFFFFFF
PAGE_OFFSET
z/OS:
0 GB
1 GB
2 GB
Java Heap
0x0
0x40000000
VM Resources
WebSphere Support Technical Exchange
0x7FFFFFFF
37
IBM Software Group
Theoretical and Advised Max Heap
Sizes The larger the Java heap, the more constrained the native heap
Advised limits to prevent native heap from becoming overly
restricted, leading to OutOfMemoryErrors
Platform
Additional Options
Maximum Possible
Advised Maximum
AIX
automatic
3.25 GB
2.5GB
2 GB
1.5GB
3 GB
2.5GB
1.8GB
1.5GB
1.8GB
1.8GB
1.7GB
1.3GB
Linux
Hugemem Kernel
Windows
/3GB
z/OS
Exceeding advised limits possible, but should be done only when
native heap usage is understood
Native heap usage can be measured using OS tools:
Svmon (AIX), PerfMon (Windows), RMF (zOS) etc
WebSphere Support Technical Exchange
38
IBM Software Group
Moving to 64bit
Moving to 64bit remove the Java heap size limit
However, ability to use more memory is not free
64bit applications perform slower
More data has to be manipulated
Cache performance is reduced
64bit applications require more memory
Java Object references are larger
Internal pointers are larger
Major improvements to this in Java 6.0 due to compressed pointers
WebSphere Support Technical Exchange
39
IBM Software Group
The correct Java heap size
GC will adapt heap size to keep occupancy between 40% and 70%
Heap occupancy over 70% causes frequent GC cycles
Which generally means reduced performance
Heap occupancy below 40% means infrequent GC cycles, but cycles
longer than they needs to be
Which means longer pause times that necessary
Which generally means reduced performance
The maximum heap size setting should therefore be 43% larger than the
maximum occupancy of the application
Maximum occupancy + 43% means occupancy at 70% of total heap
Eg. For 70MB occupancy, 100MB Max heap required, which is 70MB +
43% of 70MB
WebSphere Support Technical Exchange
40
IBM Software Group
The correct Java heap size
Heap Size
Too Frequent Garbage Collection
Memory
70%
Heap Occupancy
40%
Long Garbage Collection Cycles
Time
WebSphere Support Technical Exchange
41
IBM Software Group
Fixed heap sizes vs. Variable heap sizes
Should the heap size be fixed?
i.e. Minimum heap size (-Xms) = Maximum heap size (-Xmx)?
Each option has advantages and disadvantages
As for most performance tuning, you must select which is right for the particular
application
Variable Heap Sizes
GC will adapt heap size to keep occupancy between 40% and 70%
Expands and Shrinks the Java heap
Allows for scenario where usage varies over time
Where variations would take usage outside of the 40-70% window
Fixed Heap Sizes
Does not expand or shrink the Java heap
WebSphere Support Technical Exchange
42
IBM Software Group
Heap Expansion and Shrinkage
Act of heap expansion and shrinkage is relatively cheap
However, a compaction of the Java heap is sometimes required
Expansion: for some expansions, GC may have already
compacted to try to allocate the object before expansion
Shrinkage: GC may need to compact to move objects from the
area of the heap being shrunk
Whilst expansion and shrinkage optimizes heap occupancy, it
(usually) does so at the cost of compaction cycles
WebSphere Support Technical Exchange
43
IBM Software Group
Conditions for Heap Expansion
Not enough free space available for object allocation after GC has
complete
Occurs after a compaction cycle
Typically occurs where there is fragmentation or during rapid
occupancy growth (i.e., application startup)
Heap occupancy is over 70%
Compaction unlikely
More than 13% of time is spent in GC
Compaction unlikely
WebSphere Support Technical Exchange
44
IBM Software Group
Conditions for Heap Shrinkage
Heap occupancy is under 40%
And the following is not true:
Heap has been recently expanded (last 3 cycles)
GC is a result of a System.GC() call
Compaction occurs if:
An object exists in the area being shrunk
GC did not shrink on the previous cycle
Compaction is therefore likely to occur
WebSphere Support Technical Exchange
45
IBM Software Group
Introduction to Xmaxf and Xminf
The Xmaxf and Xminf settings control the 40% and 70% occupancy
bounds
-Xmaxf: the maximum heap space free before shrinkage (default is 0.6
for 40%)
-Xminf: the minimum heap space before expansion (default is 0.3 for
70%)
Can be used to move optimum occupancy window if required by the
application
eg. Lower heap utilization required for more infrequent GC cycles
Can be used to prevent shrinkage
-Xmaxf1.0 would mean shrinkage only when heap is 100% free
Would completely remove shrinkage capability
WebSphere Support Technical Exchange
46
IBM Software Group
Introduction to Xmaxe and -Xmine
The Xmaxe and Xmine settings control the bounds of the size of
each expansion step
-Xmaxe: the maximum amount of memory to add to the heap
size in the case of expansion (default is unlimited)
-Xmine: the minimum amount of memory to add to the heap
size in the case of expansion (default is 1MB)
Can be used to reduce/prevent compaction due to expansion
Reduce expansions by setting a large -Xmine
WebSphere Support Technical Exchange
47
IBM Software Group
GC Managed Heap Sizing
Heap Size
Expansion (>= -Xmine)
To Frequent Garbage Collection
Memory
-Xminf
Heap Occupancy
-Xmaxf
Long Garbage Collection Cycles
Time
WebSphere Support Technical Exchange
48
IBM Software Group
Fixed or Variable??
Again, dependent on application
For flat memory usage, use fixed
For widely varying memory usage, consider variable
Variable provides more flexibility and ability to avoid
OutOfMemoryErrors
Some of the disadvantages can be avoided:
-Xms set to lowest steady state memory usage prevents
expansion at startup
-Xmaxf1 will remove shrinkage
-Xminf can be used to prevent compaction before
expansion
-Xmine can be used to reduce expansions
WebSphere Support Technical Exchange
49
IBM Software Group
Heap Sizing for Generational GC
Options Are:
Fix both nursery and tenured space
Nursery
Tenured
Allow them to expand/contract
General Advice:
Fix the new space size
Size the tenured space as you would for a flat heap
WebSphere Support Technical Exchange
50
IBM Software Group
Sizing the Nursery
Copying from Allocate to Survivor or to Tenured space is expensive
Physical data is copied (similar to compaction with is also expensive
Ideally survival rates should be as low as possible
Less data needs to be copied
Less tenured/global collects that will occur
The larger the nursery:
the greater the time between collects
the less objects that should survive
However, the longer a copy can potentially take
Recommendation is to have a nursery as large as possible
Whilst not being so large that nursery collect times affect the
application responsiveness
WebSphere Support Technical Exchange
51
IBM Software Group
Summary
GC Policy should be chosen according to application scenario
Java heap should ideally be sized for between 40 and 70%
occupancy
Min=Max heap size is right for some applications, but not for others
WebSphere Support Technical Exchange
52
IBM Software Group
Additional WebSphere Product Resources
Discover the latest trends in WebSphere Technology and implementation, participate in
technically-focused briefings, webcasts and podcasts at:
http://www.ibm.com/developerworks/websphere/community/
Learn about other upcoming webcasts, conferences and events:
http://www.ibm.com/software/websphere/events_1.html
Join the Global WebSphere User Group Community: http://www.websphere.org
Access key product show-me demos and tutorials by visiting IBM Education Assistant:
http://www.ibm.com/software/info/education/assistant
View a Flash replay with step-by-step instructions for using the Electronic Service
Request (ESR) tool for submitting problems electronically:
http://www.ibm.com/software/websphere/support/d2w.html
Sign up to receive weekly technical My support emails:
http://www.ibm.com/software/support/einfo.html
WebSphere Support Technical Exchange
53
IBM Software Group
Additional Java Product Resources
Obtain Java Documentation:
https://www.ibm.com/developerworks/java/jdk/docs.html
Download the IBM Java SDKs:
https://www.ibm.com/developerworks/java/jdk/index.html
Find and download Java tooling:
http://www.ibm.com/software/websphere/events_1.html
Troubleshoot Java with the IBM Guided Activity Assistant:
http://www-01.ibm.com/support/docview.wss?uid=swg27010135
Troubleshoot Java with the Guided Troubleshooting InfoCenter
http://publib.boulder.ibm.com/infocenter/javasdk/tools/topic/com.ibm.java.doc.tools.welc
ome/tools/welcome/welcome.html
Discuss IBM Java:
http://www.ibm.com/developerworks/forums/forum.jspa?forumID=367
WebSphere Support Technical Exchange
54
IBM Software Group
Questions and Answers
WebSphere Support Technical Exchange
55