IBM Java Garbage Collection Tuning

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
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
IBM Software Group
Selecting the Correct GC Policy
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
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
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
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
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
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
10
IBM Software Group
Parallel Mark/Parallel Sweep view of GC
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
12
IBM Software Group
Parallel and Concurrent Mark/Sweep
Concurrent Kickoff
13
IBM Software Group
Concurrent Mark hidden object issue

Higher heap usage
14
IBM Software Group
Concurrent Mark hidden object issue

Higher heap usage
Dangling pointer!
because not all garbage removed
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

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
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
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.
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
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
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
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%
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
24
IBM Software Group

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
25
IBM Software Group
Gencon provides less frequent long Garbage Collection cycles

Gencon provides a shorter longest Garbage Collection cycle
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
27
IBM Software Group
Sizing the Java Heap
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
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
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
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
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
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
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
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
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
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
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
39
IBM Software Group

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
40
IBM Software Group
Heap Size
Too Frequent Garbage Collection
Memory
70%
Heap Occupancy
40%
Long Garbage Collection Cycles
Time
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
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
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
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
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
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
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
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
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
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
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
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
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
54
IBM Software Group
Questions and Answers
55

IBM Java Garbage Collection Tuning

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

IBM Java Garbage Collection Tuning

Caricato da

Copyright:

Formati disponibili

IBM Software Group

Java Garbage Collection

Best Practices for Sizing and Tuning the Java Heap

WebSphere Support Technical Exchange

IBM Software Group

WebSphere Support Technical Exchange

IBM Software Group

Garbage Collection Performance

WebSphere Support Technical Exchange

IBM Software Group

Selecting the Correct GC Policy

WebSphere Support Technical Exchange

IBM Software Group

Understanding Garbage Collection

WebSphere Support Technical Exchange

IBM Software Group

Available for objects < 512 bytes in size

IBM Software Group

Object Reclamation (Garbage Collection)

A programmatically requested garbage collection cycle

Two main technologies used to remove the garbage:

WebSphere Support Technical Exchange

IBM Software Group

Global Collection Policies

WebSphere Support Technical Exchange

optimized for batch type applications

IBM Software Group

WebSphere Support Technical Exchange

IBM Software Group

WebSphere Support Technical Exchange

IBM Software Group

Parallel Mark/Parallel Sweep view of GC

WebSphere Support Technical Exchange

IBM Software Group

Concurrent Marking and Concurrent Sweeping

Slight overhead on thruput for greatly reduced STW times

WebSphere Support Technical Exchange

IBM Software Group

Parallel and Concurrent Mark/Sweep

WebSphere Support Technical Exchange

IBM Software Group

Concurrent Mark hidden object issue

WebSphere Support Technical Exchange

IBM Software Group

Concurrent Mark hidden object issue

because not all garbage removed

WebSphere Support Technical Exchange

IBM Software Group

Generational and Concurrent GC (gencon)

Nursery (new) Space

Ideal for transactional and high data throughput workloads

IBM Software Group

Nursery (new) Space Copy Collection

Nursery is split into two spaces (semi-spaces)

WebSphere Support Technical Exchange

IBM Software Group

WebSphere Support Technical Exchange

IBM Software Group

Looking for Heap Lock Contention

Provides time accounting and contention statistics for

IBM Software Group

JLA Sample Report

REC TIER2 TIER3 %UTIL AVER-HTM MON-NAME

Java (Inflated) Monitors