Theory of Memory Managementwhile Running The Scripts
Theory of Memory Managementwhile Running The Scripts
Memory Management
1
Memory Mgmt and the JVM
The JVM Specification doesnt say how to
manage the heap
Performance Criteria
Throughput
How much work does my application complete?
Latency (promptness)
How long might my application pause (due to a
memory management)?
Memory footprint
How much memory is required by the
application above whats needed for its work?
2
Garbage Collection (GC)
Many GC Techniques
3
Reachability
An object is reachable if it can be accessed by
chasing pointers from live data
Safe policy: delete unreachable objects
An unreachable object can never be accessed again by
the program (the object is definitely garbage).
A reachable object may be accessed in the future (the
object could be garbage but will be retained anyway).
Could lead to memory leaks
How to implement reachability?
What data is live?
How to perform pointer chasing?
7
Roots
At a given program point, we define liveness as
being data reachable from the root set:
Global variables (i.e., static fields)
Local variables of all live method activations (i.e., the
stack)
At the machine level, we also consider the register
set (usually stores local or global variables)
4
Reference Counting
Old technique (1960)
Each object tracks the number of pointers to it
from other objects and from the roots.
When count reaches 0, object can be deallocated
Counts incremented/decremented by the compiler
(auto) or by hand (manual) when program
statements create or remove aliases.
10
5
Reference Counting Example
stack
121
11
12
6
Reference Counting Example
stack
121
10
13
14
7
Reference Counting Example
stack
1210
15
16
8
Tradeoffs with Ref Counting
Advantage: Incremental technique
Small amount of work per memory write
With more effort, can bound running time
Useful for real-time systems
Problems:
Data on cycles cant be collected; counts never go to 0
Cascading decrements can be expensive
E.g., when an aggregate data structure that is dropped
17
9
Mark and Sweep Example
stack
19
20
10
Mark and Sweep Example
stack
21
22
11
Mark and Sweep Example
stack
23
24
12
Mark and Sweep Example
stack
25
Cons:
Fragmentation
Cost proportional to heap size
Sweep phase needs to traverse whole heap
26
13
Copying GC
Like mark and sweep, but only touches live
objects
Divide heap into two equal parts (semispaces)
Only one semispace active at a time
GC copies data from one to the other
Trace the live data starting from the stack
Copy live data into other semispace
Declare everything in current semispace dead;
switch to other semispace
27
Copying GC Example
stack
28
14
Copying GC Example
stack
29
Copying GC Example
stack
30
15
Copying GC Example
stack
31
Copying GC Tradeoffs
Pros:
Only touches live data
No fragmentation; automatically compacts
Will probably increase locality
Cons:
Requires twice the memory space
Like mark and sweep, need to stop the world
32
16
The Generational Principle
Young
objects
die quickly;
More objects live
old objects
keep living
Generational Collection
Divide heap into generations
Objects that survive many collections get
pushed into older generations
Older generations collected less often
Need to track pointers from old to young
generations to use as roots for young generation
collection
Usually implemented with a write barrier
34
17
HotSpot SDK 1.4.2 Collector
35
36
18
Scaling up GC
Incremental collection
GC runs in mutator thread, but runs only for a short
time and then resumes
Concurrent collection
GC thread runs in parallel with the mutator
Parallel collection
Many GC threads, all running in parallel
HotSpot VM
38
19
Metronome
39
20
Dealing with GC Problems
Best idea: Measure where your problems are
coming from
For HotSpot VM, try running with
-verbose:gc
Prints out messages with statistics when a GC occurs
GC Parameters
Can resize the generations
How much to use initially, plus max growth
Change the total heap size
In terms of an absolute measure
In terms of ratio of free/allocated data
For server applications, two common tweaks:
Make the total heap as big as possible
Make the young generation half the total heap
42
21
Increasing Memory Performance
Dont allocate as much memory
Less work for your application
Less work for the garbage collector
Should improve performance
(Why only should?)
22
Bad Ideas (Usually)
Calling System.gc()
This is probably a bad idea
You have no idea what the GC will do
And it will take a while
java.lang.ref
46
23
SoftReference
Constructor SoftReference(Object o)
Make a soft reference to object o
Access using get() method
47
WeakReference
Constructor WeakReference(Object o)
48
24
PhantomReference
49
50
25
Caveat for Weak References
Which is correct?
WeakReference wr = ; WeakReference wr = ;
obj = wr.get(); obj = wr.get();
if (obj == null) { if (obj == null) {
obj = new A(); wr = new WeakRef(new A());
wr = new WeakRef(obj); obj = wr.get();
} }
From Haggar, Garbage Collection and the Java Platform Memory Model
51
52
26