1. Practical Lessons in
Memory Analysis
Andrew Johnson
advisory software engineer
IBM United Kingdom Limited

2. 2
Based on TS-4118 at JavaOne 2009
Original presentation by
• Krum Tsvetkov - SAP AG
• Andrew Johnson – IBM United Kingdom Limited

3. 3
Goal
Learn practical tips and tricks for the
analysis of common memory-related
problems

4. 4
Agenda
Introduction
Analyzing Memory Leaks
Analyzing a Heavy Request
Reducing Memory Footprint
Non-heap Memory
Summary
Q & A

5. 5
Why care about memory?
Memory is a crucial resource
Excessive memory usage can cause:
• Crashes in the application
• Unresponsive applications
• Unpredictable program behavior
Memory analysis is complicated

6. 6
How will this session help me?
Present common memory-related issues
Give hints how to solve them using heap
dumps and Memory Analyzer
Show many demonstrations using real-life
heap dumps
Show how to simplify analysis by
automating it

7. 7
Heap dumps are useful for analysis
Heap dumps come “for free”
They are suitable for production
The comprehensive data allows detailed
analysis
There is wide platform coverage
• HPROF dumps from HotSpot based JVMs
• DTFJ system dumps from IBM JVMs
• Portable Heap Dumps (PHD) file from IBM JVMs
JSR-326/Apache Kato standardization
• http://incubator.apache.org/projects/kato.html

8. 8
Agenda
Introduction
Analyzing Memory Leaks
Analyzing a Heavy Request
Reducing Memory Footprint
Non-heap Memory
Summary
Q & A

9. 9
First, collect data for analysis
Enable heap dumps on OutOfMemoryError
Trigger heap dumps on demand if needed
How-to for getting a heap dump:
http://wiki.eclipse.org/index.php/MemoryAnalyzer#Gett

10. 10
How to get a “good” heap dump
 When memory is exhausted the leak will occupy
most of the processing space
 Ensure big enough processing space, this will make
the leak easier to find
Max
Heap
Min
Heap
Processing
Space
Base
Memory

11. 11
How to analyze memory leaks
Find the biggest objects
Analyze why they are kept in memory
Analyze what makes them big

12. 12
Demonstration
 Analysis of a Memory Leak

13. 13
How the leak analysis was done
Got a “good” heap dump
Found the biggest objects (in the dominator
tree)
Analyzed who kept them alive (using paths)
Analyzed what made them big (looking at
their retained set)
Used “Leak Report” to automate the
analysis

14. 14
Agenda
Introduction
Analyzing Memory Leaks
Analyzing a Heavy Request
Reducing Memory Footprint
Non-heap Memory
Summary
Q & A

15. 15
What is a heavy request?
An expensive operation which can cause an
OutOfMemoryError
“Acute” rather than a “chronic” problem
Examples:
• Reading a big file in memory not in chunks
• Try to load a whole DB table in memory

16. 16
Inspect the thread to find its activity
Look at the thread attributes - name, class,
etc...
Look at the local variables
Look at the stack of the thread

17. 17
Demonstration
Analysis of a Heavy Request

18. 18
How thread activity was analyzed
Inspected thread attributes and local
variables (in object explorer)
Analyzed stack trace

19. 19
Agenda
Introduction
Analyzing Memory Leaks
Analyzing a Heavy Request
Reducing Memory Footprint
Non-heap Memory
Summary
Q & A

20. 20
Why is memory footprint important?
 A lower memory footprint can improve:
• The scaling of an application / server
• Performance by increasing the time between GCs
Max
Heap
Min
Heap
Processing
Space
Base
Memory

21. 21
Find where footprint can be optimized
Inspect the set of retained objects
Search for inefficiently used data structures
Look for redundant data

22. 22
Demonstration
• Analysis of High Memory Footprint

23. 23
How memory footprint was analyzed
Analyzed retained objects (in dominator
tree, retained set)
Used “Group by Value” to find redundant
objects
Used the commands from the “Collections”
group
Used “Component Report” to automate the
analysis

24. 24
Agenda
Introduction
Analyzing Memory Leaks
Analyzing a Heavy Request
Reducing Memory Footprint
Non-heap Memory
Summary
Q & A

25. 25
Non-heap memory can be exhausted
What is in the non-heap memory?
• Metadata for classes
• Interned Strings (for some JVMs)
• NIO direct byte buffers
• Bitmaps
How can it be exhausted?
• Too many interned Strings
• Classes packaged and loaded multiple times
• Class loaders which are not properly released

26. 26
Why is a class loader not released?
 The trivial case – there
is a “normal” reference
to it
 A common case – it is
the context class loader
of a thread
 The registry problem –
one instance is enough
Class loader
Class Class
Instance Instance Instance InstanceInstance
Registry
Root

27. 27
How to analyze “leaking” class loaders
Find classes loaded more than once
Find redundant loaders by their name
Look at the paths to the suspect class
loaders

28. 28
Demonstration
Analysis of “Leaking” Class Loaders

29. 29
How “leaking” class loaders analysis was done
Used the “Duplicate Classes” query
Found the loaders that load redundant
classes
Analyzed why they are not released (using
paths)

30. 30
Agenda
Introduction
Analyzing Memory Leaks
Analyzing a Heavy Request
Reducing Memory Footprint
Non-heap Memory
Summary
Q & A

31. 31
Summary
Heap dumps are very helpful for memory
analysis
Memory Analyzer offers rich analysis feature
set
The analysis can often be automated

32. 32
Questions and answers
Memory Analyzer homepage @ Eclipse
• http://www.eclipse.org/mat/
• Binary downloads
• Source downloads
• Forum
• Getting started guide
• Frequently asked questions
• Bug reports

33. 33
Thank you
Andrew Johnson
• IBM United Kingdom Limited
Memory Analyzer homepage @ Eclipse
• http://www.eclipse.org/mat/
IBM Support Assistant
• http://www-01.ibm.com/software/support/isa/
• IBM Monitoring and Diagnostic Tools – Memory
Analyzer