Post on 11-Nov-2014
description
© 2013 IBM Corporation
Chris Bailey – IBM Java Service Architect
26th September 2013
Memory-Efficient Java Code Write low overhead application code
Document number
© 2013 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
© 2013 IBM Corporation3
Introduction to the speaker 13 years experience developing and deploying Java SDKs
Recent work focus:– Java applications in the cloud– Java usability and quality– Debugging tools and capabilities– Requirements gathering– Highly resilient and scalable deployments–
My contact information:– baileyc@uk.ibm.com– http://www.linkedin.com/in/chrisbaileyibm– http://www.slideshare.net/cnbailey/
© 2013 IBM Corporation4
Goals of this talk
Understand the memory usage of Java code
Minimize the creation of new objects
Choose the right collection types
Analyze your application for memory inefficiencies
© 2013 IBM Corporation5
Java Memory Usage
© 2013 IBM Corporation6
Anatomy of a Java Object
A: Option 5: 128bits (4:1)
public static void main(String[] args) {Integer myInteger = new Integer(10);
}
Q: An int value is 32bits. How big is an Integer object? (on 32bit)– Option 1: 32 bits (1:1)– Option 2: 48 bits (1.5:1)– Option 3: 64 bits (2:1)– Option 4: 96 bits (3:1)
© 2013 IBM Corporation7
Anatomy of a Java Object
Typical Object Metadata:
0 32 64 96 128 160 192 224 256 288 320
Class pointer Flags Locks int: 10
Class pointer Flags Locks int: 10Size
Java Object
Array Object
public static void main(String[] args) {Integer myInteger = new Integer(10);
}
– 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)
© 2013 IBM Corporation8
Anatomy of a Java Object: 64bit
0 32 64 96 128 160 192 224 256 288 320
Java Object
Array Object
public static void main(String[] args) {Integer myInteger = new Integer(10);
}
Class pointer Flags Locks intClass pointer Flags Locks int, eg. 10
Class pointer Flags Locks intSizeClass pointer Flags Locks int, eg. 10Size
Size ratio of an Integer object to an int value becomes 9:1 !!
Typical Object Metadata:– 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)
© 2013 IBM Corporation9
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
© 2013 IBM Corporation10
Anatomy of a Java Object: 64bit with Compressed Refs/OOPs
0 32 64 96 128 160 192 224 256 288 320
Java Object
Array Object
public static void main(String[] args) {Integer myInteger = new Integer(10);
}
Class pointer Flags Locks intClass pointer Flags Locks int, eg. 10
Class pointer Flags Locks intSizeClass pointer Flags Locks int, eg. 10Size
Typical Object Metadata:– 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)
© 2013 IBM Corporation11
Object Field SizesField Type Field size/bits
32bit 64bit CompressedObject Array Object Array Object Array
boolean 32 8 32 8 32 8byte 32 8 32 8 32 8char 32 16 32 16 32 16short 32 16 32 16 32 16int 32 32 32 32 32 32float 32 32 32 32 32 32long 64 64 64 64 64 64double 64 64 64 64 64 64Objects 32 32 64 64 32 32
© 2013 IBM Corporation12
Allocating (slightly) more complex objects
Good object orientated design encourages encapsulation and delegation
Example: java.lang.String encapsulates a character array:
Class pointer Flags Locks hash
Class pointer Flags Locks Size
java.lang.Stringcount offset value
charM
charY
charS
charT
charR
charI
charN
charG char[]
public static void main(String[] args) {String myString = new String("MyString");
}
0 32 64 96 128 160 192 224 256 288 320
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!
© 2013 IBM Corporation13
Summary
Objects are (much) larger than the data you store in them– Allows Java to do memory management– Allows Java to provide synchronization on your data– Allows tools to analyze and visualize application memory
32bit vs 64bit has an effect on your memory usage– Use CompressedOOPs/Refs to mitigate additional Object overhead
More recent Java VMs also have other memory improvements– Lazy lock word allocation, etc
© 2013 IBM Corporation14
Object Allocation / Reclamation
© 2013 IBM Corporation15
Temporary Objects
Most Objects created by an application are “temporary”– Used as part of a calculation, transform, business transaction, etc
Temporary Objects need to be allocated and reclaimed– Memory management carried out by the Garbage Collector
Garbage Collection is a tax on your application performance– Time spent garbage collecting is time the application isn't running– Typically up to 10% of overhead
© 2013 IBM Corporation16
Allocated 0Reclaimed 0Allocated 2Reclaimed 0Allocated 4Reclaimed 0Allocated 6Reclaimed 0Allocated 8Reclaimed 0Allocated 8Reclaimed 2Allocated 8Reclaimed 4Allocated 8Reclaimed 6
String Concatenation
Concatenation of Strings using the '+' operator equates to:
String s1 = “String1”;String s2 = “String2”;
String s3 = s1 + s2;
String s3 = new StringBuilder(String.valueOf(s1)).append(s2).toString()String s1
char[] “String 1”
String s2
char[] “String 2”
char[]
String s3
char[]
StringBuilderchar[] “String 1”
char[] “String 2”
© 2013 IBM Corporation17
String Interning and String Literals
Java optimizes String usage by interning Strings– Stores unique strings in a data collection
Prevents the need to allocate Strings if they are already in the data collection– No need to allocate s1 and s2– They become references into the data collection– The intern String cache reduces are allocations to 2, and our reclamations to 1.
String literals are automatically interned by the JVM
Concatenation of final String literals is done at compile time
© 2013 IBM Corporation18
Summary
Time is spent by garbage collection removing unwanted data and Objects– Performance tax: Time spent running GC and not running your application
Allocation and reclamation can be reduced using caches– The data we need already exists
Using caches can actually reduce overall memory usage– Where data can be shared rather than copied
© 2013 IBM Corporation19
Object Caching
© 2013 IBM Corporation20
Java Collections
Each Java Collection has a different level of function, and memory overhead
Using the wrong type of collection can incur significant additional memory overhead
Incr
easi
ng F
unct
ion java.util.HashSet
java.util.HashMapjava.util.Hashtablejava.util.LinkedListjava.util.ArrayList In
crea
sing
Siz
e
© 2013 IBM Corporation21
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.“
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
public static void main(String[] args) {HashMap myHashMap = new HashMap();
}
© 2013 IBM Corporation22
HashMap StructureHashMap
array[16]
© 2013 IBM Corporation23
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
© 2013 IBM Corporation24
HashMap StructureHashMap
array[16]
HashMap$Entry
Object key
Object value
HashMap$Entry
Object key
Object value
HashMap$Entry
Object key
Object value
HashMap$Entry
Object key
Object value
HashMap$Entry
Object key
Object value
© 2013 IBM Corporation25
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. “
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
public static void main(String[] args) {LinkedList myLinkedList = new LinkedList();
}
© 2013 IBM Corporation26
LinkedList Structure
LinkedList
© 2013 IBM Corporation27
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
© 2013 IBM Corporation28
LinkedList Structure
LinkedList
LinkedList$Entry
Object value
LinkedList$Entry
Object value
LinkedList$Entry
Object value
LinkedList$Entry
Object value
© 2013 IBM Corporation29
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. “
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
public static void main(String[] args) {ArrayList myArrayList = new ArrayList();
}
© 2013 IBM Corporation30
ArrayList Structure
ArrayList
value value value value value value value value value value
© 2013 IBM Corporation31
Other types of “Collections”
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 toallocate a new internal buffer array. If the internal buffer overflows, it is automaticallymade larger.”
Implementation is an array of char
Default capacity is 16 characters
Empty size is 72 bytes
Overhead is just 24bytes for StringBuffer
public static void main(String[] args) {StringBuffer myStringBuffer = new StringBuffer();
}
© 2013 IBM Corporation32
StringBuffer Structure
StringBuffer
char char char char char char char char char char char char char char char char
© 2013 IBM Corporation33
Collections Summary
Collection Default Capacity Empty Size 10K OverheadHashSet 16 144 360KHashMap 16 128 360KHashtable 11 104 360KLinkedList 1 48 240KArrayList 10 88 40KStringBuffer 16 72 24
© 2013 IBM Corporation34
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!
© 2013 IBM Corporation35
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
java.lang.StringBuffer
char[]
0 32 64 96 128 160 192 224 256 288 320
Class Flags Locks count
Class Flags Locks charSize
value
charcharcharcharcharcharcharcharcharcharcharcharcharcharcharM Y S T R I N G
352 384 416 448 480 512 544 576 608 640
StringBuffer default of 16 is inappropriate to hold a 9 character string– 7 additional entries in char[]– 112 byte additional overhead
public static void main(String[] args) { StringBuffer myStringBuffer = new StringBuffer(“MyString”);}
© 2013 IBM Corporation36
Expansion of collections
When collections hit the limit of their capacity, they expand– Greatly increases capacity– Greatly reduces “fill ratio”
Introduces additional collection overhead:
java.lang.StringBuffer
char[]
0 32 64 96 128 160 192 224 256 288 320
Class Flags Locks count
Class Flags Locks charSize
value
charcharcharcharcharcharcharcharcharcharcharcharcharcharcharcharcharcharcharcharcharcharcharcharcharcharcharcharcharcharM Y S T R I N G O F T E X T
352 384 416 448 480 512 544 576 608 640
Additional 16 char[] entries to hold single extra character– 240 byte additional overhead
© 2013 IBM Corporation37
Collections Summary
Collection Default Capacity Empty Size 10K Overhead ExpansionHashSet 16 144 360K x2HashMap 16 128 360K x2Hashtable 11 104 360K x2 + 1LinkedList 1 48 240K +1ArrayList 10 88 40K x1.5StringBuffer 16 72 24 x2
© 2013 IBM Corporation38
Conclusions
There is a memory footprint vs performance trade-off
Hash* collections are much larger, but have better search/insert/delete performance– x9 the size of an ArrayList– Constant access times vs linear increase with size.
Large collections avoid resizing, but increase memory overhead– Collections expand by reallocation– Collections do not automatically shrink
• Can be achieved via manual reallocation and copy
© 2013 IBM Corporation39
Application Analysis
© 2013 IBM Corporation40
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:
16% of the Java heap used just for the collection objects !!
HashTable 262,234 instances, 26.5MB of Java heapWeakHashMap 19,562 instances 12.6MB of Java heapHashMap 10,600 instances 2.3MB of Java heapArrayList 9,530 instances 0.3MB of Java heapHashSet 1,551 instances 1.0MB of Java heapVector 1,271 instances 0.04MB of Java heapLinkedList 1,148 instances 0.1MB of Java heap
TreeMap 299 instances 0.03MB of Java heap306,195 42.9MB
© 2013 IBM Corporation41
Analyzing your Collections
Eclipse Memory Analyzer Tool (MAT) provides Collection analysis:
© 2013 IBM Corporation42
Analyzing your Collections
Can select a specific Collection (java.util.Hashtable) or any
© 2013 IBM Corporation43
Analyzing your Collections
Shows 127,016 empty java.util.Hashtable instances!
© 2013 IBM Corporation44
Analyzing your Collections
You can “List objects” to see what they are
© 2013 IBM Corporation45
Analyzing your Collections
java.util.Hashtable objects being used to store session data!
© 2013 IBM Corporation46
Collection Analysis for PlantsByWebSphere Example
Over 50% of collections are empty in our example
Collection Number Empty % EmptyHashtable 262,234 127,016 48.8WeakHashMap 19,562 19,456 99.5HashMap 10,600 7,599 71.7ArrayList 9,530 4,588 48.1HashSet 1,551 866 55.8Vector 1,271 622 48.9Total 304,748 160,156 52.6
© 2013 IBM Corporation47
Improvements in the JDK: WeakHashMap
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
WeakHashMap 19,562 19,456 99.5
© 2013 IBM Corporation48
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
Size collections correctly– 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
© 2013 IBM Corporation49
Summary
There is significant overhead to your data!
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
© 2013 IBM Corporation51
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
© 2013 IBM Corporation52
Copyright and Trademarks
© IBM Corporation 2013. 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