Chris Bailey

Java Support, Monitoring and Serviceability

AVP Expert Call Series

Exclusively for AVP Clients

Java Runtime Memory Management

How the Java Runtime uses memory

© 2014 IBM Corporation

Important Disclaimers

THE INFORMATION CONTAINED IN THIS PRESENTATION IS PROVIDED FOR INFORMATIONAL PURPOSES

ONLY.

WHILST EFFORTS WERE MADE TO VERIFY THE COMPLETENESS AND ACCURACY OF THE INFORMATION
CONTAINED IN THIS PRESENTATION, IT IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED.

ALL PERFORMANCE DATA INCLUDED IN THIS PRESENTATION HAVE BEEN GATHERED IN A CONTROLLED
ENVIRONMENT. YOUR OWN TEST RESULTS MAY VARY BASED ON HARDWARE, SOFTWARE OR
INFRASTRUCTURE DIFFERENCES.

ALL DATA INCLUDED IN THIS PRESENTATION ARE MEANT TO BE USED ONLY AS A GUIDE.

IN ADDITION, THE INFORMATION CONTAINED IN THIS PRESENTATION IS BASED ON IBM’S CURRENT

PRODUCT PLANS AND STRATEGY, WHICH ARE SUBJECT TO CHANGE BY IBM, WITHOUT NOTICE.

IBM AND ITS AFFILIATED COMPANIES SHALL NOT BE RESPONSIBLE FOR ANY DAMAGES ARISING OUT OF
THE USE OF, OR OTHERWISE RELATED TO, THIS PRESENTATION OR ANY OTHER DOCUMENTATION.

NOTHING CONTAINED IN THIS PRESENTATION IS INTENDED TO, OR SHALL HAVE THE EFFECT OF:

- CREATING ANY WARRANT OR REPRESENTATION FROM IBM, ITS AFFILIATED COMPANIES OR ITS OR
THEIR SUPPLIERS AND/OR LICENSORS

2 From Java Code to Java Heap: Understanding the Memory Usage of Your Application © 2014 IBM Corporation
Introduction to the speaker

3 From Java Code to Java Heap: Understanding the Memory Usage of Your Application © 2014 IBM Corporation
Goals of this talk

■ Deliver an insight into the memory usage of Java code:

– The overhead of Java Objects
– The cost of delegation
– The overhead of the common Java Collections

■ Provide you with information to:

– Choose the right collection types
– Analyze your application for memory inefficiencies

4 From Java Code to Java Heap: Understanding the Memory Usage of Your Application © 2014 IBM Corporation
Agenda

■ Introduction to Memory Management

■ Anatomy of a Java object

■ Understanding Java Collections

■ Analyzing your application

5 From Java Code to Java Heap: Understanding the Memory Usage of Your Application © 2014 IBM Corporation
Understanding Java Memory Management

■ Java runs as a Operating System (OS) level process, with the restrictions that the OS
imposes:
0 GB 2 GB 4 GB
-Xmx

OS and C-Runtime JVM Native Heap Java Heap(s)

0x40000000 0xC0000000
0x0 0x80000000 0xFFFFFFFF

■ 32 bit architecture and/or OS gives 4GB of process address space

– Much, much larger for 64bit

■ Some memory is used by the OS and C-language runtime

– Area left over is termed the “User Space”

■ Some memory is used by the Java Virtual Machine (JVM) runtime

■ Some of the rest is used for the Java Heap(s)
…and some is left over: the “native” heap
■ Native heap is usually measured including the JVM memory usage

6 From Java Code to Java Heap: Understanding the Memory Usage of Your Application © 2014 IBM Corporation
Java objects with “native” resources

■ A number of Java objects are underpinned by OS level resources

– Therefore have associated “native” heap memory

■ Example: java.lang.Thread

Java Heap Native Heap

7 From Java Code to Java Heap: Understanding the Memory Usage of Your Application © 2014 IBM Corporation
Anatomy of a Java Object

public class CreateInteger {

public static void main(String[] args) {

Integer myInteger = new Integer(10);
}

■ Question: An int (eg. 10) is 32 bits, but how much bigger is an Integer object?
(for a 32bit platform)
(a) x1
(b) x1.5
(c) x2
(d) x3

■ Answer is option (e) x4 !!

8 From Java Code to Java Heap: Understanding the Memory Usage of Your Application © 2014 IBM Corporation
Anatomy of a Java Object
public static void main(String[] args) {
Integer myInteger = new Integer(10);
}

■ Object Metadata: 3 slots of data (4 for arrays)

– Class: pointer to class information
– Flags: shape, hash code, etc
– Lock: flatlock or pointer to inflated monitor
– Size: the length of the array (arrays only)
Size/Bits
0 32 64 96 128 160 192 224 256 288 320

Class pointer Flags Locks int, eg. 10 Java Object

Class pointer Flags Locks Size int, eg. 10 Array Object

■ Additionally, all Objects are 8 byte aligned (16 byte for CompressedOops with large heaps)

9 From Java Code to Java Heap: Understanding the Memory Usage of Your Application © 2014 IBM Corporation
Anatomy of a 64bit Java Object
public static void main(String[] args) {
Integer myInteger = new Integer(10);
}

■ Object Metadata: 3 slots of data (4 for arrays)

– Class: pointer to class information
– Flags: shape, hash code, etc
– Lock: flatlock or pointer to inflated monitor
– Size: the length of the array (arrays only)
Size/Bits
0 32 64 96 128 160 192 224 256 288 320

Class pointer
Class pointer
Flags Locks Flags int Locks int, eg. 10 Java Object

Class pointer
Class pointer
Flags Locks Flags Size int Locks Size int, eg. 10 Array Object

■ Size ratio of an Integer object to an int value becomes x9 !!

10 From Java Code to Java Heap: Understanding the Memory Usage of Your Application © 2014 IBM Corporation
Object Field Sizes

Field Type Field size/bits

32bit Process 64bit Process
Object Array Object Array
boolean 32 8 32 8
byte 32 8 32 8
char 32 16 32 16
short 32 16 32 16
int 32 32 32 32
float 32 32 32 32
long 64 64 64 64
double 64 64 64 64
Objects 32 32 64* 64
*32bits if Compressed References / Compressed Oops enabled

11 From Java Code to Java Heap: Understanding the Memory Usage of Your Application © 2014 IBM Corporation
Compressed References and CompressedOOPs

■ Migrating an application from 32bit to 64bit Java increases memory usage:

– Java heap usage increases by ~70%
– “Native” heap usage increases by ~90%

■ Compressed References / Compressed Ordinary Object Pointers

– Use bit shifted, relative addressing for 64bit Java heaps
– Object metadata and Objects references become 32bits

■ Using compressed technologies does remove Java heap usage increase

■ Using compressed technologies does not remove “native” heap usage increase

12 From Java Code to Java Heap: Understanding the Memory Usage of Your Application © 2014 IBM Corporation
Allocating (slightly) more complex objects

■ Good object orientated design encourages encapsulation and delegation

■ Simple example: java.lang.String containing “MyString”:
public static void main(String[] args) {
String myString = new String("MyString");
} Size/Bits
■ 0 32 64 96 128 160 192 224 256 288 320

Class pointer Flags Locks hash count offset value java.lang.String

■

■
char char char char char char char char
Class pointer Flags Locks Size
M Y T I G
char[]
■ S R N

■ 128 bits of char data, stored in 480 bits of memory, size ratio of x3.75
– Maximum overhead would be x24 for a single character!

■
13 From Java Code to Java Heap: Understanding the Memory Usage of Your Application © 2014 IBM Corporation
Java Collections

■ Each Java Collection has a different level of function, and memory overhead
java.util.HashSet
Increasing Function

Increasing Size
java.util.HashMap
java.util.Hashtable
java.util.LinkedList
java.util.ArrayList
■ Using the wrong type of collection can incur significant additional memory overhead

14 From Java Code to Java Heap: Understanding the Memory Usage of Your Application © 2014 IBM Corporation
HashSet
public static void main(String[] args) {
HashSet myHashSet = new HashSet();
}

■ Implementation of the Set interface

– “A collection that contains no duplicate elements. More formally, sets contain no pair
of elements e1 and e2 such that e1.equals(e2), and at most one null element. As
implied by its name, this interface models the mathematical set abstraction. “
● Java Platform SE 6 API doc

■ Implementation is a wrapper around a HashMap:

■ Default capacity for HashSet is 16

■ Empty size is 144 bytes
■ Additional 16 bytes / 128 bits overhead for wrappering over HashMap

15 From Java Code to Java Heap: Understanding the Memory Usage of Your Application © 2014 IBM Corporation
HashMap
public static void main(String[] args) {
HashMap myHashMap = new HashMap();
}

■ Implementation of the Map interface:

– “An object that maps keys to values. A map cannot contain duplicate keys; each key
can map to at most one value.“
● Java Platform SE 6 API doc

■ Implementation is an array of HashMap$Entry objects:

■ Default capacity is 16 entries

■ Empty size is 128 bytes
■ Overhead is 48 bytes for HashMap, plus (16 + (entries * 4bytes)) for array
– Plus overhead of HashMap$Entry objects

16 From Java Code to Java Heap: Understanding the Memory Usage of Your Application © 2014 IBM Corporation
HashMap$Entry

■ Each HashMap$Entry contains:

– int KeyHash
– Object next
– Object key
– Object value

■ Additional 32bytes per key ↔ value entry

■ Overhead of HashMap is therefore:
– 48 bytes, plus 36 bytes per entry

■ For a 10,000 entry HashMap, the overhead is ~360K

17 From Java Code to Java Heap: Understanding the Memory Usage of Your Application © 2014 IBM Corporation
Hashtable
public static void main(String[] args) {
Hashtable myHashtable = new Hashtable();
}

■ Implementation of the Map interface:

– “This class implements a hashtable, which maps keys to values. Any non-null object
can be used as a key or as a value.“
● Java Platform SE 6 API doc

■ Implementation is an array of Hashtable$Entry objects:

■ Default capacity is 11 entries

■ Empty size is 104 bytes
■ Overhead is 40 bytes for Hashtable, plus (16 + (entries * 4bytes)) for array
– Plus overhead of Hashtable$Entry objects

18 From Java Code to Java Heap: Understanding the Memory Usage of Your Application © 2014 IBM Corporation
Hashtable$Entry

■ Each Hashtable$Entry contains:

– int KeyHash
– Object next
– Object key
– Object value

■ Additional 32bytes per key ↔ value entry

■ Overhead of Hashtable is therefore:
– 40 bytes, plus 36 bytes per entry

■ For a 10,000 entry Hashtable, the overhead is ~360K

19 From Java Code to Java Heap: Understanding the Memory Usage of Your Application © 2014 IBM Corporation
LinkedList
public static void main(String[] args) {
LinkedList myLinkedList = new LinkedList();
}

■ Linked list implementation of the List interface:

– “An ordered collection (also known as a sequence). The user of this interface has
precise control over where in the list each element is inserted. The user can access
elements by their integer index (position in the list), and search for elements in the
list.
– Unlike sets, lists typically allow duplicate elements. “
● Java Platform SE 6 API doc

■ Implementation is a linked list of LinkedList$Entry objects (or LinkedList$Link):

■ Default capacity is 1 entry

■ Empty size is 48 bytes
■ Overhead is 24 bytes for LinkedList, plus overhead of LinkedList$Entry/Link objects

20 From Java Code to Java Heap: Understanding the Memory Usage of Your Application © 2014 IBM Corporation
LinkedList$Entry / Link

■ Each LinkedList$Entry contains:

– Object previous
– Object next
– Object entry

■ Additional 24bytes per entry

■ Overhead of LinkedList is therefore:
– 24 bytes, plus 24 bytes per entry

■ For a 10,000 entry LinkedList, the overhead is ~240K

21 From Java Code to Java Heap: Understanding the Memory Usage of Your Application © 2014 IBM Corporation
ArrayList
public static void main(String[] args) {
ArrayList myArrayList = new ArrayList();
}

■ A resizeable array instance of the List interface:

– “An ordered collection (also known as a sequence). The user of this interface has
precise control over where in the list each element is inserted. The user can access
elements by their integer index (position in the list), and search for elements in the
list.
– Unlike sets, lists typically allow duplicate elements. “
● Java Platform SE 6 API doc

■ Implementation is an array of Object:

■ Default capacity is 10 entries

■ Empty size is 88 bytes
■ Overhead is 32bytes for ArrayList, plus (16 + (entries * 4bytes)) for array
■ For a 10,000 entry ArrayList, the overhead is ~40K
22 From Java Code to Java Heap: Understanding the Memory Usage of Your Application © 2014 IBM Corporation
Other types of “Collections”
public static void main(String[] args) {
StringBuffer myStringBuffer = new StringBuffer();
}

■ StringBuffers can be considered to be a type of collection

– “A thread-safe, mutable sequence of characters...
....
– Every string buffer has a capacity. As long as the length of the character sequence
contained in the string buffer does not exceed the capacity, it is not necessary to
allocate a new internal buffer array. If the internal buffer overflows, it is automatically
made larger.”
● Java Platform SE 6 API doc

■ Implementation is an array of char

■ Default capacity is 16 characters

■ Empty size is 72 bytes
■ Overhead is just 24bytes for StringBuffer

23 From Java Code to Java Heap: Understanding the Memory Usage of Your Application © 2014 IBM Corporation
Collections Summary

Collection Default Capacity Empty Size 10K Overhead

HashSet 16 144 360K
HashMap 16 128 360K
Hashtable 11 104 360K
LinkedList 1 48 240K
ArrayList 10 88 40K
StringBuffer 16 72 24

24 From Java Code to Java Heap: Understanding the Memory Usage of Your Application © 2014 IBM Corporation
Hash* collections vs others

■ Hash* collections are much larger

– x9 the size of an ArrayList

■ Additional size helps search/insert/delete performance

– Constant for Hash collections
– Linear for Array collections
● If there is no other index

■ Using the larger collection may be the right thing to do

– Important to know it is the right thing to do!

25 From Java Code to Java Heap: Understanding the Memory Usage of Your Application © 2014 IBM Corporation
Empty space in collections

■ Collections that contain empty space introduce additional overhead

■ Default collection size may not be appropriate for the amount of data being held
■ public static void main(String[] args) {
StringBuffer myStringBuffer = new StringBuffer(“MyString”);
}
0 32 64 96 128 160 192 224 256 288 320 352 384 416 448 480 512 544 576 608 640

Class Flags Locks count value java.lang.StringBuffer

Class Flags Locks Size char

M charcharcharcharcharcharchar
Y S T R I N charcharcharcharcharcharcharchar
G char[]

■ StringBuffer default of 16 is inappropriate to hold a 9 character string

– 7 additional entries in char[]
– 112 byte additional overhead

26 From Java Code to Java Heap: Understanding the Memory Usage of Your Application © 2014 IBM Corporation
Expansion of collections

■ When collections hit the limit of their capacity, they expand

– Greatly increases capacity
– Greatly reduces “fill ratio”

■ Introduces additional collection overhead:

0 32 64 96 128 160 192 224 256 288 320 352 384 416 448 480 512 544 576 608 640

Class Flags Locks count value java.lang.StringBuffer

Class Flags Locks Size char

M charcharcharcharcharcharchar
Y S T R I N charcharcharcharcharcharcharcharcharcharcharcharcharcharchar
G O F T E X T charcharcharcharcharcharcharchar char[]

■ Additional 16 char[] entries to hold single extra character

– 240 byte additional overhead

27 From Java Code to Java Heap: Understanding the Memory Usage of Your Application © 2014 IBM Corporation
Collections Summary

Collection Default Capacity Empty Size 10K Overhead Expansion

HashSet 16 144 360K x2
HashMap 16 128 360K x2
Hashtable 11 104 360K x2 + 1
LinkedList 1 48 240K +1
ArrayList 10 88 40K x1.5
StringBuffer 16 72 24 x2

28 From Java Code to Java Heap: Understanding the Memory Usage of Your Application © 2014 IBM Corporation
Collections Summary

■ Collections exist in large numbers in many Java applications

■ Example: IBM WebSphere Application Server running PlantsByWebSphere

– When running a 5 user test load, and using 206MB of Java heap:
HashTable 262,234 instances, 26.5MB of Java heap
WeakHashMap 19,562 instances 12.6MB of Java heap
HashMap 10,600 instances 2.3MB of Java heap
ArrayList 9,530 instances 0.3MB of Java heap
HashSet 1,551 instances 1.0MB of Java heap
Vector 1,271 instances 0.04MB of Java heap
LinkedList 1,148 instances 0.1MB of Java heap
TreeMap 299 instances 0.03MB of Java heap
306,195 42.9MB

■ 16% of the Java heap used just for the collection objects !!

29 From Java Code to Java Heap: Understanding the Memory Usage of Your Application © 2014 IBM Corporation
Analyzing your Collections

■ Eclipse Memory Analyzer Tool (MAT) provides Collection analysis:

30 From Java Code to Java Heap: Understanding the Memory Usage of Your Application © 2014 IBM Corporation
Analyzing your Collections

■ Can select a specific Collection (java.util.Hashtable) or any

31 From Java Code to Java Heap: Understanding the Memory Usage of Your Application © 2014 IBM Corporation
Analyzing your Collections

■ Shows 127,016 empty java.util.Hashtable instances!

32 From Java Code to Java Heap: Understanding the Memory Usage of Your Application © 2014 IBM Corporation
Analyzing your Collections

■ You can “List objects” to see what they are

33 From Java Code to Java Heap: Understanding the Memory Usage of Your Application © 2014 IBM Corporation
Analyzing your Collections

■ java.util.Hashtable objects being used to store session data!

34 From Java Code to Java Heap: Understanding the Memory Usage of Your Application © 2014 IBM Corporation
Collection Analysis for PlantsByWebSphere Example

Collection Number Empty % Empty

Hashtable 262,234 127,016 48.8
WeakHashMap 19,562 19,456 99.5
HashMap 10,600 7,599 71.7
ArrayList 9,530 4,588 48.1
HashSet 1,551 866 55.8
Vector 1,271 622 48.9
Total 304,748 160,156 52.6

■ Over 50% of collections are empty in our example

35 From Java Code to Java Heap: Understanding the Memory Usage of Your Application © 2014 IBM Corporation
Improvements in the JDK: WeakHashMap

WeakHashMap 19,562 19,456 99.5

■ 12.5MB of memory being used for 19,456 empty instances of WeakHashMap

■ 560 bytes per instance used for java.lang.ref.ReferenceQueue

– ReferenceQueue only required is there are elements in the WeakHashMap

■ Lazy allocation of ReferenceQueue saves 10.9MB in our example

36 From Java Code to Java Heap: Understanding the Memory Usage of Your Application © 2014 IBM Corporation
Techniques for minimizing memory

■ Lazy allocation of collections

– Don't create a collection until you have something to put into it

■ Don't create collections for a single Object!

– Just store the Object itself

■ Correct sizing of collections

– If only 2 entries will be stored, create with size 2:
HashMap myHashMap = new HashMap(2);

■ Avoid expansion of large collections due to x2 algorithm

– 32MB used to store 17MB of data

■ Collections do not shrink once expanded

– May need to reallocate if collection uses drops significantly

37 From Java Code to Java Heap: Understanding the Memory Usage of Your Application © 2014 IBM Corporation
Summary

■ There is significant overhead to your data!

– Some of which is on the “native” heap

■ Applications often have:

– The wrong collection types in use
– Empty or sparsely populated collections

■ Careful use of:

– Data structure layout
– Collection type selection
– Collection type default sizing

Can improve your memory efficiency

■ Eclipse Memory Analyzer Tool can identify inefficiencies in your application

– As well as show you the wider memory usage for code

38 From Java Code to Java Heap: Understanding the Memory Usage of Your Application © 2014 IBM Corporation
Questions?

Upcoming Java Expert Call Series

39 From Java Code to Java Heap: Understanding the Memory Usage of Your Application © 2014 IBM Corporation
 Backup

40 From Java Code to Java Heap: Understanding the Memory Usage of Your Application © 2014 IBM Corporation
Process Memory Monitoring

■ Monitoring of native heap carried out by monitoring the process size

– Java heap and VM usage are static, so process size growth is the native heap

■ Exhaustion of the process address space shows native heap exhaustion

– Leads to OutOfMemoryError as would Java heap exhaustion

■ Native heap is managed using OS malloc/free routines

■ Therefore OS tools are best place to monitor memory usage

■ GC and Memory Visualiser (GCMV) in ISA can visualize some OS tool output:
– AIX, Linux, Windows, z/OS

■ Health Center can do live monitoring of native memory usage:

– AIX, Linux, Windows, z/OS

41 © 2011 IBM Corporation

Process Memory Monitoring: Windows

■ Recommended tool is “perfmon”

– In Control Panel -> Admin Tools -> Performance
– Can also be started using “perfmon” on the command line

■ Displays a number of counters for a given process

■ Relevant counter is “Virtual Bytes”
– memory that has been allocated, ie. a malloc() request has been made

■ “Working Set” may also be on interest

– memory that is committed to, ie. has been written to and is actively in use

■ NB: Maximum Java heap size is allocated at start up

– but only the Minimum heap size is written to (committed)

42 © 2011 IBM Corporation

Perfmon log

■ Perfmon can log to text (.csv) file or binary

■ CSV file format is as follows:
"(PDH-CSV 4.0) (GMT Daylight Time)(-60)","\\MY_COMP\Process(java)\Virtual Bytes"
"05/08/2008 16:33:56.859","1198592000"
"05/08/2008 16:34:11.859","1198592000"
"05/08/2008 16:34:26.859","1198592000"
"05/08/2008 16:34:41.859","1198592000"
"05/08/2008 16:34:56.859","1198592000"

■ Can be imported into other tooling:

– GCMV!
– Spreadsheet
– Database
– etc

43 © 2011 IBM Corporation

Process Memory: PerfMon View

44 © 2011 IBM Corporation

Process Memory Monitoring: AIX

■ Recommended tool is “svmon”

– Available on the AIX install image
– Started using “svmon –P {pid} –m –r –i {interval}”

■ Displays a per segment breakdown of memory

– Relevant value is “Addr Range” for heap segments
– memory that has been allocated, ie. a malloc() request has been made
– Relevant heap segments according to AIX memory layout

45 © 2011 IBM Corporation

Process Memory: Svmon Output

Pid Command Inuse Pin Pgsp Virtual 64-bit Mthrd

25084 AppS 78907 1570 182 67840 N Y
Vsid Esid Type Description Inuse Pin Pgsp Virtual Addr Range
2c7ea 3 work shmat/mmap 36678 0 0 36656 0..65513
3c80e 4 work shmat/mmap 7956 0 0 7956 0..65515
5cd36 5 work shmat/mmap 7946 0 0 7946 0..65517
14e04 6 work shmat/mmap 7151 0 0 7151 0..65519
7001c d work shared library text 6781 0 0 736 0..65535
0 0 work kernel seg 4218 1552 182 3602 0..22017 :
65474..65535
6cb5a 7 work shmat/mmap 2157 0 0 2157 0..65461
48733 c work shmat/mmap 1244 0 0 1244 0..1243
cac3 - pers /dev/hd2:176297 1159 0 - - 0..1158
54bb5 - pers /dev/hd2:176307 473 0 - - 0..472
78b9e - pers /dev/hd2:176301 454 0 - - 0..453
58bb6 - pers /dev/hd2:176308 254 0 - - 0..253
cee2 - work 246 17 0 246 0..49746
4cbb3 - pers /dev/hd2:176305 226 0 - - 0..225
7881e - pers /dev/e2axa702-1:2048 186 0 - - 0..1856
68f5b - pers /dev/e2axa702-1:2048 185 0 - - 0..1847
28b8a - pers /dev/hd2:176299 119 0 - - 0..118

46 © 2011 IBM Corporation

Analysing Native Memory with GCMV

■ Garbage Collection and Memory Visualizer (GCMV) is available as part of ISA

■ GCMV provides scripts to capture the data in the help file

■ Visualization makes it easier to see trends over time

– Look for memory leak
– Look for native heap footprint issues

47 © 2011 IBM Corporation

Analysing Process Memory in GCMV

48 © 2011 IBM Corporation

Monitoring GC activity

■ Monitor GC live using Health Center from ISA

– Very low (<1%) cost live monitoring of a single Java instance

■ Use of Verbose GC logging

– Activated using command line options:

-verbose:gc
-Xverbosegclog:[DIR_PATH][FILE_NAME]
-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, very small – cost of I/O to stderr/file only
● basic testing shows a <1ms overhead per GC cycle

49 © 2011 IBM Corporation

Analysing Verbose GC output

■ A number of tools exist for plotting verbose:gc output

■ Recommendation: Garbage Collection and Memory Visualizer (GCMV)

– Developed, maintained and supported by IBM Java Tools team
– https://www.ibm.com/developerworks/java/jdk/tools/gcmv/

■ Available with in ISA:

– http://www-306.ibm.com/software/support/isa/

■ GCMV will visualise verbose:gc data from the following JVMs

– IBM, Oracle* and HP
– 1.4.2, 5.0, 6.0, 7.0
– WebSphere RealTime 1.0, 2.0 and 3.0

– *No support for Oracle G1GC yet.

50 © 2011 IBM Corporation

Sizing Deployments

■ Check native heap usage before increasing Java heap size

– Especially for large Java heaps on 32bit

■ Ensure enough physical memory is available for all running processes

– Use “Reserved Address Space (Virtual Memory)” value in GCMV

■ Ensure additional physical memory is available for filesystem/IO caching

– Typically a minimum of 10% of RAM is assigned to file caching

51 © 2011 IBM Corporation

References

■ Get Products and Technologies:

– IBM Monitoring and Diagnostic Tools for Java:
● https://www.ibm.com/developerworks/java/jdk/tools/
– Eclipse Memory Analyzer Tool:
● http://eclipse.org/mat/downloads.php
●

■ Learn:
– Debugging from Dumps:
● http://www.ibm.com/developerworks/java/library/j-memoryanalyzer/index.html
– Why the Memory Analyzer (with IBM Extensions) isn't just for memory leaks
anymore:
● http://www.ibm.com/developerworks/websphere/techjournal/1103_supauth/1103_supauth.html

■ Discuss:
– IBM on Troubleshooting Java Applications Blog:
● https://www.ibm.com/developerworks/mydeveloperworks/blogs/troubleshootingjava/
– IBM Java Runtimes and SDKs Forum:
● http://www.ibm.com/developerworks/forums/forum.jspa?forumID=367&start=0

52 From Java Code to Java Heap: Understanding the Memory Usage of Your Application © 2014 IBM Corporation
Copyright and Trademarks

© IBM Corporation 2011. All Rights Reserved.

IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International
Business Machines Corp., and registered in many jurisdictions worldwide.

Other product and service names might be trademarks of IBM or other companies.

A current list of IBM trademarks is available on the Web – see the IBM “Copyright and
trademark information” page at URL: www.ibm.com/legal/copytrade.shtml

53 From Java Code to Java Heap: Understanding the Memory Usage of Your Application © 2014 IBM Corporation