Java Memory Hogs.pdf

Copyright © 2013, Oracle and/or its affiliates. All rights reserved. Confidential – Oracle Internal
1

2
Abstract
After analyzing 670 Java heap dumps from across Oracle products,
interesting memory hogs emerge. There are several memory-reducing
optimizations for middleware and application programmers as well as
the JVM and JDK. These optimizations will significantly reduce the
memory usage of Java programs and perhaps decrease response times.

3
Java Memory Hogs
Nathan Reynolds
Exalogic Performance Architect
Memory

4
The following is intended to outline our general product
direction. It is intended for information purposes only,
and may not be incorporated into any contract. It is not a
commitment to deliver any material, code, or
functionality, and should not be relied upon in making
purchasing decisions. The development, release, and
timing of any features or functionality described for
Oracle’s products remains at the sole discretion of
Oracle.

5
Introduction
PSR
Vikram Kumar
Applications
…
Middleware
…
Platform
Ashim Kohli
Exalogic
Exalytics
...
...
…
…
…
…
…
DB Queries
…
…
…
…

6
Introduction
Team Responsibilities
 Weblogic
 Coherence
 Oracle Traffic Director
 HotSpot & JDK
 Linux
 OVM
 ODI
 GoldenGate
 Exabus (aka Infinibus)
 ZFS
 EMOC
 Business Intelligence
 TimesTen
 Essbase
 Data Quality

7
Acknowledgements
 Misha Dmitriev’s JOverflow tool and bug fixing support.
– http://oraclelabs.us.oracle.com/people/misha/bin/

8
Program Agenda
 Methodology
 Statistics
 Strings
 Object Headers
 Arrays
 Collections
 Hash Collections
 Other
 Wrap Up

9
Methodology

10
Problem Description
 Optimize HotSpot and Weblogic to have most impact on applications.
 Already have engineers optimizing application code.
 JIT is already well optimized.
 Java memory usage is typically 2x of C++ programs.
 Optimize the platform so that application memory usage is lowered.
 Need to optimize for all applications and not just one or two.
 How do I get a variety of heap dumps?

11
Process Flow
1 2 3 4
Scan Unzip
Download JOverflow
5
Parse
6
Aggregate

12
Process Flow
1 2 3 4
Scan Unzip
Download JOverflow
5
Parse
6
Aggregate

13
Process Flow
1 2 3 4
Scan Unzip
Download JOverflow
5
Parse
6
Aggregate

14
Process Flow
1 2 3 4
Scan Unzip
Download JOverflow
5
Parse
6
Aggregate

15
Process Flow
1 2 3 4
Scan Unzip
Download JOverflow
5
Parse
6
Aggregate

16
Process Flow
1 2 3 4
Scan Unzip
Download JOverflow
5
Parse
6
Aggregate

17
Process Flow
1 2 3 4
Scan Unzip
Download JOverflow
5
Parse
6
Aggregate

18
Execution Time
 The program ran for about 100 hours.
 Processed 670 heap dumps.
 706 GB of heap dumps analyzed.
 19,652 aggregate statistics collected.

20
Caveats
 Most of Oracle products are servers.
 Some work loads represented more than other workloads.
 Not all work loads represented.
 Something went wrong with the work load.
– Out of memory?
– Memory leak?
– Memory regression?
1 of 2

21
Caveats
 Heap dumps are a snap shot in time. No trends or prior knowledge.
 GCs are typically not forced before the heap dump is taken.
 Derivation calculations assume 32-bit JVM with 8-byte header.
2 of 2

22
Surprising Benefits
Heap Response Time
ATG CRM Demo 13% 16%
ADF FOD 8% 19%
CRM Sales Opportunity 11% 7%
 Reducing memory usage, reduces time in GC.
 Lowering GC time, reduces average response time.
Lazily Initialize HashMap and ArrayList

23
Statistics

24
 Bytes are always powers of 1,024.
 Instance counts are always powers of 1,000.
 Dashes “-” mean the amount is below the reporting threshold of 0.1%
 Compare mean to median to see where the outliers are.
Statistics Format
Mean ± St Dev Min Median Max
Percent 24.4% ± 12.0% - 25.3% 82.6%
Bytes 245 MB ± 274 MB - 170 MB 2.05 GB
Count 2.01 M ± 2.14 M 9.29 k 1.48 M 23.9 M

25
 The above statistics are for the used heap space (not max heap).
 3 MB heap was a simple JMS sender program.
 Average object size is 67.7 bytes (including object header).
– Slightly bigger than an Intel x86 cache line.
– False sharing between objects should be easy to solve.
 Most popular objects: String, char[], Object[], ArrayList, HashMap
Heap Usage
Percent 100% ± 0.0% 100% 100% 100%
Bytes 1.04 GB ± 970 MB 3.00 MB 931 MB 6.58 GB
Count 16.5 M ± 15.0 M 55.6 k 13.3 M 97.7 M

26
Primitive Arrays,
2.46 M, 14.6%
Object Arrays,
2.23 M, 13.3%
Strings,
2.09 M, 12.4%
Collections,
1.10 M, 6.5%
Boxed Numbers,
0.28 M, 1.7%
Other Instances,
8.64 M, 51.5%
Instance Count Breakdown

27
 Unknown heap size impact.
– Hprof does not report java.lang.Class instances properly.
– Estimate the impact from java.lang.Class to be insignificant on average.
 JIT still working after 2 hours when using large numbers of classes!
java.lang.Class
Percent ? ± ? ? ? ?
Bytes ? ± ? ? ? ?
Count 43.5 k ± 41.2 k 1.16 k 31.7 k 490 k

28
No Instances,
25.7 k, 59.0%
One Instance,
11.8 k, 27.1%
Multiple
Instances,
6.04 k, 13.9%,
2.73 k instances
per class
Class Count Breakdown

29
Strings

30
 ¼ of heap consumed by Strings. Watch out for Strings!
 Don’t encode numbers into Strings.
 Average String size (including headers and metadata) is 126 bytes.
 Average String length is 45 characters.
– Assumes pre-JDK 7 Update 6
Strings
Percent 24.4% ± 12.2% - 25.4% 82.6%
Bytes 244 MB ± 275 MB - 167 MB 2.05 GB
Count 2.03 M ± 2.26 M - 1.49 M 23.9 M

31
Strings
 Java: 2-byte characters.
 Save 7.3% heap space.
 Works only if upper-bytes are all 0.
Compressed
0 H 0 e 0 l 0 l 0 o
H e l l o
Percent 14.5% ± 9.1% - 14.3% 81.3%
Bytes 153 MB ± 206 MB 229 kB 100 MB 1.87 GB
Count 2.02 M ± 2.25 M 7.10 k 1.47 M 23.9 M
char[ ] =
byte[ ] =

32
Strings
 Makes Strings compressible.
 Oracle DB uses UTF-8 to compact text data and reduce space.
 Significant CPU savings.
UTF-8
Web
Server
DB
Server
Application
Server
Convert
to
UTF-8
Convert
to
UCS-2

33
UTF-8 Article
Wikipedia.org
“…text in Chinese, Japanese or Hindi could take more
space in UTF-8... This happens for pure text, but rarely
for HTML documents. For example, both the Japanese
UTF-8 and the Hindi Unicode articles on Wikipedia take
more space in UTF-16 than in UTF-8.”

34
 String.intern() stores 1ˢᵗ String in a weak hash table.
 String constants in classes are passed through String.intern().
 Use String.intern() in non-performance critical code.
– Will increase Permanent Generation space (pre HotSpot 8 concern)
– Hash table/array size is constant.
– Need to tune the size or performance will suffer
 -XX:StringTableSize=##### where ##### is a prime number
Strings
Percent 13.5% ± 8.8% 0.0% 13.4% 68.3%
Bytes 150 MB ± 198 MB 129 kB 90.3 MB 1.46 GB
Count 116 k ± 118 k 278 93.0 k 1.11 M
Duplicates (1 of 2)

35
 String.equals() could de-duplicate char[ ] in Strings.
 Background thread to de-duplicate char[ ] in Strings in the entire heap.
– Well-placed String.intern() will perform better.
– XML parsers need de-duplication but may not be able to use String.intern()
Strings
Percent 13.5% ± 8.8% 0.0% 13.4% 68.3%
Bytes 150 MB ± 198 MB 129 kB 90.3 MB 1.46 GB
Count 116 k ± 118 k 278 93.0 k 1.11 M
Duplicates (2 of 2)

36
 “” – empty – consider a private static final char[0] – saves 292 kB
 “0” – zero
 “name”
 “true”
 “false”
 “N”
Strings
Popular Duplicates

37
 Data represents String memory if de-duplicate and compress.
 Didn’t calculate standard deviation or maximum.
Strings
Percent 5.5% ± ? - 6.0% ?
Bytes 47 MB ± ? - 38.4 MB ?
Remainder

38
Object Headers

39
 HotSpot has an Object header size of 8, 12 or 16 bytes.
– 32-bit JVM uses 8-byte headers (80.8% of heaps)
– 64-bit JVM uses 16-byte headers (6.8% of heaps)
– 64-bit JVM with compressed references uses 12-byte headers (12.5%)
 Arrays add 4 more bytes for the length of the array.
Object Headers
Percent 13.9% ± 4.5% 0.3% 13.5% 28.6%
Bytes 137 MB ± 128 MB 434 kB 107 MB 874 MB
Count 16.5 M ± 15.0 M 55.6 k 13.3 M 97.7 M
Introduction

40
 Bad idea to combine classes to reduce total number of instances.
– Conflicts with single-responsibility software-design principle.
– Conflicts with rarely used field problem (discussed later).
Object Headers
Program Consideration

41
Object Headers
Content Layout
 Current 8-byte Object header
 4-byte Object header impact
– Saves about 7% of heap space – more savings on 64-bit
Identity Hash: 25
GC Age: 4 Biased Lock: 1 Lock Flags: 2 Class*: 32
JavaThread*: 23 Epoch: 2

42
 Plain old java.lang.Object
 Do we really need that many plain-old Objects?
 Are these used as locks to hide synchronization from the API?
Object
Percent 0.1% ± 0.2% - - 1.4%
Bytes 354 kB ± 1.28 MB - - 12.6 MB
Count 35.0 k ± 131 k - - 1.40 M
Introduction

43
Arrays

44
 98.4% comes from Coherence Servers.
– Stores cached objects as byte[ ].
 Average size 439 bytes (including array header).
– 2.7% from array header
 Use DirectByteBuffers for I/O buffers.
– Avoids having to copy the data when perform I/O operation.
 Cautiously use byte[ ] pools.
byte[ ]
Percent 12.5% ± 17.9% - 4.5% 98.4%
Bytes 124 MB ± 279 MB - 35.5 MB 2.78 GB
Count 296 k ± 1.05 M - 75.7 k 15.8 M

45
 Statistics for all arrays and includes empty and zero-tail.
 Average size 215 bytes.
 Average length 50.8 elements.
 Cautiously use int[ ] pools.
 Can anything be done in the JVM?
int[ ]
Percent 2.7% ± 5.2% - 0.9% 60.1%
Bytes 22.8 MB ± 90.2 MB - 7.54 MB 1.22 GB
Count 111 k ± 325 k - 59.6 k 6.29 M

46
 Is this a test artifact?
– Each user retrieving the same data from the DB?
 Are char[ ] from String, StringBuilder or StringBuffer? No
 All primitive arrays have duplicates
– 1 heap reports duplicate double[ ]
– 1 heap reports duplicate float[ ]
 Consider de-duplicating on program-by-program basis.
Duplicate Primitive Arrays
Percent 8.3% ± 11.7% 0.1% 4.6% 89.6%
Bytes 90.4 MB ± 236 MB 64 kB 38.1 MB 2.73 GB
Count 20.6 k ± 55.7 k 185 10.9 k 681 k

47
Popular Values
Type Length Value
long 1 0
char 7 n
char 13 n
char 10 n
char 9 n
char 5 n
int 1 0
byte 1 0x80
int 17 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, ...
boolean 17 true, true, true, true, true, true, true, true, true, true, ...
char 4 n

48
 Memory does not include elements stored in the array.
 Average size 75.9 bytes
 Average length 16.0 elements
 Are these from java.util Collections? No
Object[ ]
Percent 6.1% ± 4.3% - 5.7% 34.0%
Bytes 66.5 MB ± 85.2 MB - 45.1 MB 0.98 GB
Count 919 k ± 1.54 M - 461 k 20.7 M

49
 Average size 102 bytes
 Programs need to lazily create the Object[ ]
Empty Object[ ]
Percent 1.0% ± 2.1% 0.0% 0.5% 29.5%
Bytes 8.38 MB ± 24.8 MB 1.00 kB 3.43 MB 503 MB
Count 86.5 k ± 405 k 12 21.8 k 6.39 M

50
 Defined as the number of non-null elements < length ÷ 2
 Bytes is the space of the null slots.
 Average size 177 bytes
 Programs need to compact the usage of the Object[ ].
Sparse Non-primitive Arrays
Percent 1.6% ± 1.4% - 1.2% 8.4%
Count 93.6k ± 216 k 62 35.3 k 3.30 M

51
 The end of the array is filled with 0.
 Average wasted size 1.67 kB.
– 75.5% of the waste comes from byte[ ]
 Suggests that the array is oversized and underutilized.
 Properly size the arrays for the data to be stored.
 Trim the length of the array once elements are removed.
Zero-tail Primitive Arrays
Percent 5.3% ± 10.9% - 1.3% 96.8%
Bytes 60.1 MB ± 188 MB 47.0 kB 10.4 MB 2.44 GB
Count 36.8 k ± 123 k 56 8.33 k 1.61 M

52
 The entire array is filled with 0.
 Average size 229 bytes.
– 42.9% of comes from byte[ ]
 Suggests that the array is pre-allocated but never used.
 Programs need to lazily create the array
Empty Primitive Arrays
Percent 2.1% ± 4.9% - 1.0% 60.6%
Bytes 21.8 MB ± 87.9 MB 18.0 kB 7.22 MB 1.32 GB
Count 100 k ± 293 k 53 35.7 k 5.12 M

53
Collections

54
Heap usage per
Collection.
Total usage: 20.1%
0.1%
0.2%
0.2%
0.4%
0.4%
0.4%
0.7%
1.1%
1.5%
1.7%
2.4%
3.5%
7.5%
0% 1% 2% 3% 4% 5% 6% 7% 8%
BitSet
WeakHashMap
IdentityHashMap
TreeMap
LinkedHashSet
LinkedList
Vector
Hashtable
HashSet
LinkedHashMap
ArrayList
ConcurrentHashMap
HashMap
Percent
Collection Breakdown
Fields

55
Unused Collections Mean ± St Dev Min Median Max
Percent 4.7% ± 5.3% - 3.7% 43.4%
Bytes 53.1 MB ± 104 MB 17 kB 27.8 MB 1.09 GB
Count 437 k ± 926 k 49 194 k 10.0 M
Percent 1.4% ± 2.9% - 0.8% 28.2%
Bytes 18.3 MB ± 67.0 MB - 4.92 MB 723 MB
Count 139 k ± 479 k - 39.6 k 4.99 M
Percent 1.0% ± 2.6% - 0.4% 27.8%
Bytes 11.0 MB ± 35.0 MB - 2.94 MB 380 MB
Count 161 k ± 477 k - 41.1 k 4.98 M
Total
ArrayList
HashMap
 Created collections
but never had a size()
> 0.
 HashMap is used in
HashSet,
LinkedHashMap and
other classes.

56
Unused Collections
Heap Response Time
ATG CRM Demo 13% 16%
ADF FOD 8% 19%
CRM Sales Opportunity 11% 7%
 Don’t allocate internal array in constructor.
 Allocate internal array upon first put() or add() call.
 Preserves initial capacity constructor argument.
 Better optimization: Don’t create collections until last moment possible.
 Could the JVM throw away unused Collections and lazily create later?
Lazily Initialize HashMap and ArrayList

57
 Defined as 4 or fewer elements.
 Bytes is the overhead of having the collection.
 Add fields to parent class instead of using a collection.
– No homegrown generic collections.
 Hash collections could use an array instead.
Small Collections
Percent 5.8% ± 4.1% - 5.6% 31.0%
Count 495 k ± 675 k 355 276 k 7.74 M

58
HashMap, 1.5%
ConcurrentHash
Map, 1.1%
LinkedHashMap,
0.8%
ArrayList, 0.7%
HashSet, 0.4%
Hashtable, 0.3%
Vector, 0.2%
Other, 0.8%
Small Collections

59
 Defined as the number of elements half of the collection’s capacity.
– 2 * size ≤ capacity
 Bytes is the overhead of empty slots in the collection.
 Properly size the capacity of the collection.
– Converts collection into a small collection and its problems.
– JVM: Collect statistics and feed back into allocation.
Small Sparse Collections
Percent 2.0% ± 1.6% - 1.9% 17.3%
Count 399 k ± 551 k 140 218 k 5.75 M

60
ConcurrentHash
Map, 0.6%
HashMap, 0.5%
ArrayList, 0.3%
LinkedHashMap,
0.2%
HashSet, 0.1%
Other, 0.3%

61
 Collections that contain boxed numbers.
 Fixed Num project would not reclaim this memory.
– Have to implement the collection differently.
Boxed Number Collections
Percent 1.2% ± 2.6% - 0.6% 25.5%
Count 55.0 k ± 262 k 7 10.5 k 3.37 M

62
 Bytes reported would be saved if used primitive numbers.
 Fixed Num project would reclaim this insignificant memory.
Boxed Numbers
Percent 0.3% ± 0.9% - 0.1% 13.3%
Bytes 4.00 MB ± 16.43 MB - 1.14 MB 313 MB
Count 280 k ± 1.04 M 56 82.9 k 17.4 M

63
 Large sparse (0.8%) – 2 * size ≤ capacity && capacity > default
 Empty used (0.4%) – collections that contained at least 1 element at
some point in time but are empty at the time of the heap dump.
Other Insignificant Collection Analyses

64
 Sizes do not include
elements.
 Average size is 76.2
bytes.
 Total size due to all
previously discussed
issues!
ArrayList Mean ± St Dev Min Median Max
Percent 2.5% ± 3.0% - 2.0% 30.1%
Bytes 27.2 MB ± 45.3 MB - 13.5 MB 396 GB
Count 374 k ± 612 k - 169 k 5.04 M
Percent 0.8% ± 1.0% - 0.6% 10.2%
Bytes 9.00 MB ± 14.9 MB - 4.15 MB 115 MB
Percent 1.7% ± 2.0% - 1.3% 19.9%
Bytes 18.2 MB ± 30.9 MB - 8.90 MB 280 MB
Total
Diff
Shallow

65
ArrayList Analysis Breakdown
Unused, 1.0%
Small, 0.7%
Small Sparse,
0.3%
Empty Used,
0.1%
Boxed Number,
0.1%
Other, 0.3%

66
Hash Collections

67
key-values.
 Average size is 257
bytes and 7.0 entries.
– Diff is 189 bytes
(73.7%)
HashMap Mean ± St Dev Min Median Max
Percent 7.4% ± 6.8% - 6.5% 55.9%
Bytes 87.5 MB ± 160 MB - 41.1 MB 1.40 GB
Count 357 k ± 729 k - 176 k 7.55 M
Percent 1.9% ± 2.0% - 1.7% 20.2%
Bytes 23.0 MB ± 49.3 MB - 10.2 MB 518 MB
Percent 5.6% ± 5.1% - 5.0% 40.5%
Bytes 64.5 MB ± 118 MB - 31.3 MB 1.12 GB
Total
Diff
Shallow

68
HashMap
Entry Overhead
 Each entry has significant overhead.
– 29⅓ bytes = 24 Entry + 4 Table ÷ 0.75 load factor
 Total Size = 29⅓ size + 52 HashMap (assuming table capacity == size)

69
HashMap Analysis Breakdown
Small, 1.5%
Unused, 1.4%
Boxed Number,
0.6%
Small Sparse,
0.5%
Large Sparse,
0.4%
Empty Used,
0.1%
Other, 2.9%

70
key-values.
 Average size is 1.44
kB.
 JDK 8 reduces unused
and per-entry
overhead.
ConcurrentHashMap Mean ± St Dev Min Median Max
Percent 3.5% ± 4.3% - 2.5% 57.2%
Bytes 34.0 MB ± 60.0 MB - 18.9 MB 877 MB
Count 24.2 k ± 49.2 k - 11.2 k 524 k
Percent 0.1% ± 0.3% - 0.1% 3.4%
Bytes 1.41 MB ± 3.05 MB - 487 kB 32.0 MB
Percent 3.4% ± 4.2% - 2.4% 55.1%
Bytes 32.6 MB ± 57.3 MB - 18.5 MB 845 MB
Total
Diff
Shallow

71
ConcurrentHashMap Analysis Breakdown
Small, 1.1%
Unused, 0.8%
Small Sparse,
0.6%
Large Sparse,
0.1%
Boxed Number,
0.1%
Empty Used,
0.1%
Other, 0.7%

72
key-values.
bytes.
 HashMap has a lower
per-entry cost.
 Benefits from Lazily
Initialize HashMap and
ArrayList.
LinkedHashMap Mean ± St Dev Min Median Max
Percent 1.7% ± 2.2% - 1.3% 40.4%
Bytes 16.0 MB ± 26.6 MB - 9.88 MB 414 MB
Count 64.1 k ± 130 k - 37.2 k 1.50 M
Percent 0.4% ± 0.6% - 0.3% 6.7%
Bytes 4.03 MB ± 6.80 MB - 2.43 MB 68.6 MB
Percent 1.3% ± 1.9% - 1.0% 33.7%
Bytes 11.9 MB ± 22.3 MB - 7.49 MB 345 MB
Total
Diff
Shallow

73
LinkedHashMap Analysis Breakdown
Small, 0.8%
Small Sparse,
0.2%
Unused, 0.1%
Boxed Number,
0.1%
Other, 0.5%

74
elements.
bytes.
 Benefits from Lazily
Initialize HashMap and
ArrayList.
 Don’t use HashMap
for HashSet’s internal
implementation.
HashSet Mean ± St Dev Min Median Max
Percent 1.5% ± 1.6% - 1.1% 16.0%
Bytes 13.8 MB ± 21.9 MB - 8.86 MB 282 MB
Count 61.9 k ± 115 k - 38.5 k 1.50 M
Percent 0.1% ± 0.1% - 0.1% 1.3%
Bytes 1.00 MB ± 1.91 MB - 606 kB 22.9 MB
Percent 1.4% ± 1.4% - 1.1% 14.7%
Bytes 12.8 MB ± 20.2 MB - 8.19 MB 259 MB
Total
Diff
Shallow

75
HashSet Analysis Breakdown
Unused, 0.5%
Small, 0.4%
Small Sparse,
0.1%
Boxed Number,
0.1%
Other, 0.4%

76
key-values.
bytes.
 Use HashMap for
code performance.
Hashtable Mean ± St Dev Min Median Max
Percent 1.1% ± 1.3% - 0.8% 14.8%
Bytes 11.6 MB ± 29.0 MB - 4.48 MB 331 MB
Count 49.9 k ± 158 k - 18.3 k 1.92 M
Percent 0.2% ± 0.3% - 0.1% 3.7%
Bytes 2.58 MB ± 8.35 MB - 799 kB 102 MB
Percent 0.8% ± 1.0% - 0.6% 11.1%
Bytes 9.05 MB ± 21.1 MB - 3.69 MB 235 MB
Total
Diff
Shallow

77
Hashtable Analysis Breakdown
Small, 0.3%
Boxed Number,
0.1%
Unused, 0.1%
Other, 0.6%

78
Collections Analysis Breakdown
Collection Small
Small
Sparse
Large
Sparse
Unused
Empty
Used
Boxed
Number
ArrayList 0.7% 0.3% - 1.0% 0.1% 0.1%
HashMap 1.5% 0.5% 0.4% 1.4% 0.1% 0.6%
ConcurrentHashMap 1.1% 0.6% 0.1% 0.8% 0.1% 0.1%
LinkedHashMap 0.8% 0.2% - 0.1% - 0.1%
HashSet 0.4% 0.1% - 0.5% - 0.1%
Hashtable 0.3% - - 0.1% - 0.1%
Total 4.8% 1.7% 0.5% 3.9% 0.3% 1.1%
 Most significant problem is a small collection.
 Lazily Initialize HashMap and ArrayList will reduce Unused overhead.

79
Other

80
 Rarely used field is defined as being null/zero in at least 90% of the
instances.
 Move rarely used fields to a Shadow Structure (details later)
Rarely Used Fields
Percent 6.9% ± 4.5% 0.1% 6.3% 40.9%
Count 4.53 M ± 4.93 M 5.99 k 3.22 M 43.8 M

81
Percentage of heap
dumps where the class
had at least 1 rarely used
field.
11.6%
13.6%
17.4%
20.2%
22.4%
23.5%
23.5%
26.1%
43.2%
44.6%
62.8%
79.2%
0% 20% 40% 60% 80%
...groovy...MetaMethodIndex$Entry
java.lang.reflect.Constructor
...jbo.server.AttributeDefImpl
...jbo.server.ViewAttributeDefImpl
ConcurrentHashMap$Segment
...XMLDocument$NodeList_cache
LinkedHashMap$Entry
LinkedHashMap
SoftReference
WeakReference
java.lang.reflect.Method
HashMap
Percent
Rarely Used Fields
Classes

82
Number of classes per
count of rarely used
fields.
2
1,943
78
217
272
691
436
568
439
679
631
0 100 200 300 400 500 600 700 800
344
10-343
9
8
7
6
5
4
3
2
1
Classes
Rarely Used Fields
Fields

83
Shadow Structure
Hog
Hog.Shadow
Object m_entrySet;
double m_threshold;
int m_size;
Shadow m_shadow;
 Requires JEP 159 Enhanced Class
Redefinition.
 To save memory, must have 5+
bytes of rarely used fields.
 Causes memory indirection.
 Putfield creates Shadow instance
using double-checked locking.
 Getfield returns 0 or null if Shadow
instance doesn’t exist.
Functionality

84
Percent 6.9% ± 4.5% 0.1% 6.3% 40.9%
Count 4.53 M ± 4.93 M 5.99 k 3.22 M 43.8 M
 Most of the Rarely
Used Fields overhead
can be saved via
Shadow Structures
Shadow Structure
Percent 4.0% ± 4.1% - 2.9% 36.1%
Bytes 46.3 MB ± 73.1 MB - 19.1 MB 684 MB
Total
Shadow
Impact
See the Beehive Workspace for a deeper discussion

85
 Will lambda’s
reduce the need
for Method?
 Rarely used fields
account for 18.2%
of Method’s
memory usage.
 85.5% of Method
instances have
rarely used fields.
Percent 1.1% ± 1.3% - 0.8% 9.2%
Bytes 9.25 MB ± 16.5 MB - 5.32 MB 210 MB
Count 75.6 k ± 122 k - 49.3 k 1.53 M
Percent 0.2% ± 0.3% - 0.2% 1.9%
Bytes 1.59 MB ± 3.26 MB - 829 kB 41.7 MB
Count 65.4 k ± 125 k - 35.0 k 1.53 M
Total
Rarely
Used

86
Percentage of heap
dumps where the field
was rarely used.
0.2%
15.8%
17.3%
17.5%
33.6%
40.0%
43.4%
52.3%
53.8%
57.8%
61.3%
0% 10% 20% 30% 40% 50% 60% 70%
root
methodAccessor
annotations
declaredAnnotations
override
signature
parameterAnnotations
genericInfo
annotationDefault
securityCheckTargetClassCache
securityCheckCache
Percent
Fields

87
Wrap Up

88
Percentage of memory
saved for each
optimization.
Total savings: 62.2%
Worth millions in saved
hardware per data center.
0.3%
1.0%
1.2%
1.6%
2.0%
2.1%
4.0%
4.7%
5.3%
5.5%
5.8%
7.0%
8.3%
13.5%
0% 2% 4% 6% 8% 10% 12% 14%
Boxed Numbers
Empty Object[]
Boxed Number Collections
Sparse Non-primitive Arrays
Empty Primitive Arrays
Rarely Used Fields
Unused Collections
Zero-tail Primitive Arrays
Compress Strings
Small Collections
Compress Object Headers
De-duplicate Strings
Percent
Memory Savings
Optimization

89
Space the Final Frontier
JVM/JDK, 31.4%
Programs
(JDK?), 12.5%
Programs, 18.3%
Future, 4.5%
Uncategorized,
17.9%
Object Headers,
7.0%
Strings, 5.5%
Rarely Used
Fields, 2.9%
Optimizable
Difficult

90
Further Analysis
 Analyze 0s inside primitives to see if smaller primitive can be used.
 Report numbers encoded into Strings.
 Correlate rarely used fields to field hiding.
 Use Pearson’s χ² test to see if hashing working well.
– Create histogram of hash bucket lengths.
 Show histogram of sizes of objects, Strings and of each Collection.
 Figure out a cheap way to find duplicate subsequences in Strings.
 Report System properties.

91
Program Optimization Task List
(1 of 3)
 Compare your heap dump to the average to identify problems.
 Collections
– Lazily create
– Properly size capacity
– Watch out for small collections
– Use HashMap instead of LinkedHashMap where possible
– Replace Hashtable with HashMap

92
(2 of 3)
 Strings
– Use UTF-8 everywhere.
– Don’t encode numbers into Strings
– Use String.intern() in non-performance critical code
 Arrays
– De-duplicate primitive arrays
– Lazily create arrays
– Properly (re)size arrays

93
(3 of 3)
 Use DirectByteBuffers for I/O buffers
 Deal with rarely used fields
 Drop references to java.lang.reflect.Method

94
HotSpot and JDK Optimization Task List
 Strings
– Compressed
– De-duplicate
– Use UTF-8 everywhere
– Dynamically size the String.intern() table
– Use private static final char[0] for empty Strings
(1 of 3)

95
 Collections
– Collect size statistics and feed back into constructor call site
– Provide collections for boxed numbers
– Make HashMap implementation cheaper
– HashSet have its own implementation and not use HashMap
– Throw away empty Collections and lazily create later?
– Reduce small Collection overhead
– Reduce rarely used fields in HashMap, Method, etc.
(2 of 3)

96
 Implement Shadow Structures
 Fixed Num project
 4-byte Object headers
(2 of 3)

97
Beehive Workspace: Java Memory Hogs
 https://stbeehive.oracle.com/teamcollab/library/st/Java+Memory+Hogs/
Documents
 Presentation slides with notes
 Audio recording
 Spreadsheet with most of the aggregate data
 Zip archive with most of the JOverflow reports
 Shadow Structure details

98
Questions & Answers

99

100

Java Memory Hogs.pdf

Recommended

Recommended

More Related Content

Similar to Java Memory Hogs.pdf

Similar to Java Memory Hogs.pdf (20)

Recently uploaded

Recently uploaded (20)

Java Memory Hogs.pdf