Click to edit the outline text format Second Outline Level Third Outline Level Fourth Outline Level Fifth Outline Level Sixth Outline Level Seventh Outline Level Eighth Outline Level Ninth Outline LevelClick to edit subtitle Click to edit the outline text format Second Outline Level Third Outline Level Fourth Outline Level Fifth Outline Level Sixth Outline Level Seventh Outline Level Eighth Outline Level Click to edit the outline text format Second Outline Level Third Outline Level Fourth Outline Level Fifth Outline Level Sixth Outline Level Seventh Outline Level Eighth Outline Level Ninth Outline LevelClick to edit presenter name, title Java Performance Memory and Runtime Analysis March 2012 Viet Nguyen, eXo CT
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
− Java Memory Problems− Common problems− Memory Leak
− Analysing Heap Dumps with Eclipse Memory Analyzer (MAT)− Shallow & Retained Size, Dominator Tree− Analysing Heap dumps with MAT
www.exoplatform.com - Copyright 2012 eXo Platform
Click to edit the outline text format
Second Outline Level
Third Outline Level Fourth Outline Level
Fifth Outline Level
Sixth Outline Level
Seventh Outline Level
Eighth Outline Level
− Ninth Outline LevelClick to edit first level• Second level• Third level
• Fourth level
• Fifth level
3
Code Performance Questions
− Did you choose the right data structure ?− Are you using the right sorting algorithm ?− Is your recursive method TOO recursive ?− Are you throwing away a computation that could prove useful
later ?− Are you creating too many objects unnecessarily or otherwise
wasting memory ?
www.exoplatform.com - Copyright 2012 eXo Platform
Click to edit the outline text format
Second Outline Level
Third Outline Level Fourth Outline Level
Fifth Outline Level
Sixth Outline Level
Seventh Outline Level
Eighth Outline Level
− Ninth Outline LevelClick to edit first level• Second level• Third level
• Fourth level
• Fifth level
4
Optimization Metrics
− Runtime / CPU usage− What line of code the program is spending the most time in− What call / invocation paths were used to get to these lines
− Memory usage− What kind of objects are sitting on the heap− Where were they allocated− Who is pointing to them now− “Memory leak”
www.exoplatform.com - Copyright 2012 eXo Platform
Click to edit the outline text format
Second Outline Level
Third Outline Level Fourth Outline Level
Fifth Outline Level
Sixth Outline Level
Seventh Outline Level
Eighth Outline Level
− Ninth Outline LevelClick to edit first level• Second level• Third level
• Fourth level
• Fifth level
5
Java's Memory Model
www.exoplatform.com - Copyright 2012 eXo Platform
Click to edit the outline text format
Second Outline Level
Third Outline Level Fourth Outline Level
Fifth Outline Level
Sixth Outline Level
Seventh Outline Level
Eighth Outline Level
− Ninth Outline LevelClick to edit first level• Second level• Third level
• Fourth level
• Fifth level
6
Java's Memory Model 2
www.exoplatform.com - Copyright 2012 eXo Platform
Click to edit the outline text format
Second Outline Level
Third Outline Level Fourth Outline Level
Fifth Outline Level
Sixth Outline Level
Seventh Outline Level
Eighth Outline Level
− Ninth Outline LevelClick to edit first level• Second level• Third level
• Fourth level
• Fifth level
7
The JVM Heaps
‘Thread Stacks
Buffers
JIT Compiled Code
Motif structures
Size
Next
Size
Next
freelist
Nullfree storage
free storage
Native Heap
Java Heap
Free List
Xms - Active Area of Heap
www.exoplatform.com - Copyright 2012 eXo Platform
Click to edit the outline text format
Second Outline Level
Third Outline Level Fourth Outline Level
Fifth Outline Level
Sixth Outline Level
Seventh Outline Level
Eighth Outline Level
− Ninth Outline LevelClick to edit first level• Second level• Third level
• Fourth level
• Fifth level
8
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
–Eg. For 70MB occupancy, 100MB Max heap is required (which is 70MB + 43% of 70MB)
− Ninth Outline LevelClick to edit first level• Second level• Third level
• Fourth level
• Fifth level
13
Java Memory Problems
− Memory leaks• Referencing objects that are no
longer used• Developer forget clear them
− Inefficient object creation• GC must constantly clean up the
heap• High CPU consumption by GC• Application response times
increases
− Unnecessarily high memory usage• Implementations consuming too
much memory• Large amount of state information• Unbound or inefficiently configured
caches• Large temporary objects: big
documents (XML, PDF, images...) are read and processed
− Inefficient garbage collector behaviour• Missing or wrong configuration of
GC
www.exoplatform.com - Copyright 2012 eXo Platform
Click to edit the outline text format
Second Outline Level
Third Outline Level Fourth Outline Level
Fifth Outline Level
Sixth Outline Level
Seventh Outline Level
Eighth Outline Level
− Ninth Outline LevelClick to edit first level• Second level• Third level
• Fourth level
• Fifth level
14
Most Common Memory Leaks
− Thread Local Variables• ThreadLocals are often used to track
state• Threads are often never garbage
collected• Memory leaks may happen if thread
local variable is not clean carefully
− Circular and complex bi-directional references• All objects will not be garbage
collected
− Mutable static fields and collections• Most common reason• Statics often used to hold caches or
share states• Memory leak happens easily if this is
not done diligently
− Wrong implementation of equals/hashcode• Lead to memory leaks when used as
a key in a map
www.exoplatform.com - Copyright 2012 eXo Platform
Click to edit the outline text format
Second Outline Level
Third Outline Level Fourth Outline Level
Fifth Outline Level
Sixth Outline Level
Seventh Outline Level
Eighth Outline Level
− Ninth Outline LevelClick to edit first level• Second level• Third level
• Fourth level
• Fifth level
15
Most Common Memory Leaks
− Classloader Leaks• Classes are referenced by their
class loader• They will not get garbage collected
until classloader itself is collected• First leak form: an object whose
class belongs to the class loader is still referenced by a cache, a thread local …
• Second leak form: Some frameworks allow dynamic creation of new classes. If they are forgotten, PermGen leaks happen
− JNI memory leaks• JNI is used to call native code• Native code can handle, call, or
create java objects• These objects are referenced until
the native method returns• First leak form: native method run
forever• Second leak form: You keep created
objects after native code has ended
www.exoplatform.com - Copyright 2012 eXo Platform
Click to edit the outline text format
Second Outline Level
Third Outline Level Fourth Outline Level
Fifth Outline Level
Sixth Outline Level
Seventh Outline Level
Eighth Outline Level
− Ninth Outline LevelClick to edit first level• Second level• Third level
• Fourth level
• Fifth level
16
How to interpret the Memory Leak Analysis Results
What is leaking?
– What is the object (e.g. a HashMap) holding all the leaking objects i.e. leak container.
– What are the objects getting added to the leak container i.e. leak unit.
– Who is holding the leak container in memory? What are the object types and package names of objects on the chain of references from a root object to the leak container i.e. owner chain.
www.exoplatform.com - Copyright 2012 eXo Platform
Click to edit the outline text format
Second Outline Level
Third Outline Level Fourth Outline Level
Fifth Outline Level
Sixth Outline Level
Seventh Outline Level
Eighth Outline Level
− Ninth Outline LevelClick to edit first level• Second level• Third level
• Fourth level
• Fifth level
17
View of the leaking data structure
Significant entities
– An owner chain
– A leak root
– A container
– The unit of the leak
– Leak contents
MyClass
HashSet
HashMap
HM$Entry
String
Char[]
HM$Entry
String
Char[]
HM$Entry
String
Char[]
Owner Chain
Leak Root
Container
Contents
Leaking Unit
www.exoplatform.com - Copyright 2012 eXo Platform
Click to edit the outline text format
Second Outline Level
Third Outline Level Fourth Outline Level
Fifth Outline Level
Sixth Outline Level
Seventh Outline Level
Eighth Outline Level
− Ninth Outline LevelClick to edit first level• Second level• Third level
• Fourth level
• Fifth level
18
Memory Leak Example
public class MyClass {
static HashSet myContainer = new HashSet();
public void leak(int numObjects) {
for (int i = 0; i < numObjects; ++i) {
String leakingUnit = new String("this is leaking object: " + i);
Problem #1: multi-GB heap dumps from 64-bit machines Quickly open and re-open a heap dump on 32-bit machines
Problem #2: millions of objects. Where is the „needle“? Dominator Tree: fast calculation of retained memory Meaningful names for class loaders: see components SQL-like language: create custom queries
Problem #3: complexity of analysis Reports on memory leak suspects and checks for known
antipatterns
Problem #4: HPROF heap dumps only Support for IBM system dumps
The Dominator Tree is a Transformation of the Cyclic Object Graph into a “Keep-Alive” Tree:
Every node in the Tree is directly responsible for keeping alive its children
Object X dominates object Y if all paths from the roots to Y run through X
Benefits: Fast calculation of the retained size (sum all children) List of distinct big objects (first level of the tree) Fast identification of responsible objects (just go up the tree)
Automatically detect memory leak suspects Discover if the issue is known (and a fix available) Collect details for in depth analysis by the code experts
Any up-to-date architecture loads components with separate class loaders, be it OSGi or JEE application servers.Extensible to display meaningful names.
Search by keywords: identify if problem is known
Classification for trouble ticket system: less ping-pong of trouble tickets.
− Ninth Outline LevelClick to edit first level• Second level• Third level
• Fourth level
• Fifth level
31
How to Analyze Memory Leaks
− Find the biggest objects− Analyze why they are kept in memory− Analyze what make them big
Use MAT To Analyze Leaks
− Get a “good” heapdump− Find the biggest objects (in the dominator tree)− Analyze who kept them alive (using paths)− Analyze what made them big (looking at their retain set)− Use “Leak report” to automate the analysis
www.exoplatform.com - Copyright 2012 eXo Platform
Click to edit the outline text format
Second Outline Level
Third Outline Level Fourth Outline Level
Fifth Outline Level
Sixth Outline Level
Seventh Outline Level
Eighth Outline Level
− Ninth Outline LevelClick to edit first level• Second level• Third level
• Fourth level
• Fifth level
32
How to Analyze a Heavy Request
− Look at the thread attributes – name, class, etc...− Look at the local variables− Look at the stack of the thread
Use MAT To Analyze Thread Activity
− Inspect threads attributes and local variables (in object explorer)
− Analyze stack trace
www.exoplatform.com - Copyright 2012 eXo Platform
Click to edit the outline text format
Second Outline Level
Third Outline Level Fourth Outline Level
Fifth Outline Level
Sixth Outline Level
Seventh Outline Level
Eighth Outline Level
− Ninth Outline LevelClick to edit first level• Second level• Third level
• Fourth level
• Fifth level
33
Find Where Memory Footprint Can Be Optimized
− Inspect the set of retained objects− Search for inefficiently used data structures− Look for redundant data
Use MAT To Analyze Memory Footprint
− Analyze retained objects (in dominator tree, retained set)− Use “Group by Value” to find redundant objects− Use the commands from the “Collections” group− Use “Component Report” to automate the analysis
− Ninth Outline LevelClick to edit first level• Second level• Third level
• Fourth level
• Fifth level
35
What to do with profiler results
− Observe which methods are being called the most− These may not necessarily be the “slowest” methods!
− Observe which methods are taking the most time relative to others− Common problem: inefficient unbuffered I/O− Common problem: poor choice of data structure− Common problem: recursion call overhead− Common problem: unnecessary re-computation of expensive
information, or unnecessary multiple I/O of same data