Garbage Collection

Garbage-Collection
Prinzipien & Algorithmen
➊ Warum Garbage Collection?
➋ Klassiﬁkation von Garbage Collection Algorithmen
➌ Einfache Ansätze:“Stop-the-World”
➍ Partitionierende Ansätze: inkrementell, generationell
➎ JVM
Tim Furche (Folien nach P. R. Wilson)
Younger Generation
Older Generation
ROOT
SET

➊
Warum Garbage Collection?
Nutzen, Einsatzgebiete

Automatische
Speicherverwaltung

Vorlesung Compilerbau,Wintersemester 2008/09
Automatische Speicherverwaltung
Stack: automatische Verwaltung einfach
wächst und schrumpft gemäß Programmablauf, Prozedursegmente, …
Compiler entscheidet über Verwaltung
Heap: unabhängig von Programmablauf
explizite Allozierung und Deallozierung notwendig
hier: Ein-Prozessor, zentralisiertes System
4
➀ Garbage Collection: Warum?

Manuelle Heap-Verwaltung aufwendig & fehleranfällig
zu konservativ: memory leak
zu aggressiv: Speicherzugriffsfehler, Null-Pointer
da schwer → inflexible, statische Verwaltung leichter
aber Gefahr von impliziten Grenzen
beeinträchtigt Wiederverwendbarkeit & loose copling
Lebensdauer von Objekten muß unter verschiedenen Komponenten abgestimmt sein
oft schwer durch Testen auffindbar
5

Strategien für manuelle Speicherverwaltung
wo soll angeforderter Speicher alloziert werden?
best fit, first fit, next fit …
Problem: Fragmentierung, schlechte Lokalität (Paging & Caching)
alloziert und dealloziert Speicher automatisch
durchschnittlich nur 10% langsamer als manuelle Speicherverwaltung
Vergleich der Schemata:
Geschwindigkeit, Vorhersehbarkeit, Einfluß auf Programmausführung
Speicherbedarf, minimale Fragmentierung, maximale Lokalität
6

Mark-and-Sweep vs. Manuel
7

8

9

10

Garbage
Garbage := aus akt. Programmzustand nicht erreichbar
statisch: ist ein Objekt einmal Garbage bleibt es es auch
global: um festzustellen, ob ein Objekt Garbage ist muss man den gesamten
Programmzustand inspizieren
Wie erkennt man Garbage?
beginne mit Root Set in den Daten
Java: Statische + lokale Variablen (auf dem Laufzeit-Stack)
Reachable := Root Set ∪ PointedTo(Reachable).
Funktioniert das auch in C?
13
Nein: – schwach typisiert (Zeiger in Integers)
– Zeigerarithmetik
– unbekannte Grenzen von Arrays …
. . .
Object 1 Object 3Object 2
Free List

Erreichbarkeit nur Approximation
Beispiel:
Nach x = y o1 nicht erreichbar, o2 erreichbar
o2 wird nie mehr verwendet
könnte also schon hier freigegeben werden
Aber: solche Programmanalyse zu teuer im allgemeinen
im folgenden: nur Erreichbarkeit
14
o1: x   = new A();
o2: y   = new B();
  x = y;
  if (true) then x = new A() else x.foo;

➋
Übersicht & Klassifikation
Garbage Collection Algorithmen

Bewertung von GC Algorithmen
Geschwindigkeit
minimiere den Einﬂuss des Algorithmus
Vorhersehbarkeit
Unterbrechung der Programmausführung: minimal
Speicherbedarf: minimal
minimale Fragmentierung
Lokalität: maximal
gemeinsam verwendete Daten nahe beinander in Cache/Seiten
17
➁ Übersicht Garbage Collection Algorithmen

Struktur von GC Algorithmen
Speicher: organisiert als Heap
verfügbarer Speicher adressierbar über Free List
Phasen der Automatische Speicherverwaltung (schematisch)
Speicherallozierung: ﬁnde freien Bereich auf dem Heap
Falls kein freier Bereich verfügbar
Garbage detection: berechne Objekte, deren Speicher wiederverwendet wd. kann
Garbage reclamation: freigeben des durch Garbage belegten Speicher
besser: freigeben auch wenn noch Speicher verfügbar ist
sonst: bei Speichermangel“stop-the-world”Eﬀekt
18
. . .
Object 1 Object 3Object 2
Free List

Typen & Klassifikation von GC Algorithmen
Counting algorithms: zählte Verweise auf Objekte
local, aber unvollständig
schwer effizient zu machen
Tracing algorithms: verfolge Verweise um Garbage zu finden
brauchen selber Speicher → können selbst zu Speicheranforderung führen
“stop-the-world” Algorithmen: berechnen Reachable am Stück
skalieren nicht, führen zu unberechenbarem Programverhalten
zeitliche Partitionierung: incremental
räumliche Partitionierung: generational
19

20
Garbage Collectors
Reference
Counters
Trace
Based
StoptheWorld ShortPause
Markand
Sweep
Markand
Compact
Basic Baker’s Basic Cheney’s
Incremental Partial
Generational Train

➌
“Stop-the-World”
Einfache GC Algorithmen

Reference counting
23
➂ Einfache GC Algorithmen
ROOT
SET
HEAP SPACE
1
1
1
2
1
1
1
2

Reference counting
24
Reference counting
Create object:
• counter := 1
• return reference
Duplicate reference:
• counter += 1
Delete reference:
Invariant: count == #refs
Continuous; cost
Cycles of garbage are not
reclaimed
v w
uroot
x
z
t
y
1
2
2!1 1
1
1
1!0

Reference counting
25
Root
Object
A(1)
E(1)D(2)
B(2)
C(1)

Reference counting
26
Root
Object
A(0)
E(1)D(2)
B(2)
C(1)

Reference counting
27
Root
Object
E(1)D(2)
B(1)
C(0)

Reference counting
28
Root
Object
E(1)D(1)
B(1)Zyklische Verweise: Referenzzähler
werden nie 0.
memory leak

Reference counting
Verwalte Anzahl der Referenzen auf jedes Objekt
lösche Objekt, sobald Referenzzähler 0
Bewertung des Algorithmus:
inkrementell, kein“stop-the-world”eﬀect
real-time: Speicher kann sobald möglich freigegeben werden
nicht vollständig: bei Zyklen kann Speicher nicht freigegeben werden
nicht eﬃzient: kurzlebige Referenzen dominieren typische Programme
Update der Referenzen bei fast jeder Zuweisung
Löschen kann kaskadieren (Anzahl der Löschungen/Updates nicht begrenzt)
29
Verzögertes Reference counting: periodische Updates für Verweise durch lokale Variablen.

Mark-and-Sweep
Zwei Phasen“stop-the-world”Algorithmus
erst markieren aller vom Root Set erreichbaren Objekte (mark)
dann aufsammeln und freigeben der nicht-markierten Objekte (sweep)
Datenstrukturen:
scanned: Erreichte und verarbeitete Objekte
unscanned: Liste der erreichten, aber noch nicht verarbeiteten Objekte
unreached: Liste der noch nicht erreichten Objekte (anfangs: alle)
free: Liste der freien Speicherplätze (vereinfacht)
30

Mark-and-Sweep
31
unreached = alle Objekte; scanned = ∅;
verschiebe Root Set von unreached nach unscanned;
while (unscanned ≠ ∅) {
o = nächstes Objekt in unscanned;
verschiebe o von unscanned nach scanned;
for all (o’ referenzierte von o)
if (noch nicht erreicht)
verschiebe o von unreached nach unscanned;
}
free = free ∪ unreached;
unscanned = scanned;
Baker’s Mark-and-Sweep: hier schon verbessert, nur allokierte werden inspiziert

Vorlesung Compilerbau,Wintersemester 2008/09 32
Prof. Aiken CS 143 Lecture 17 17
Mark-and-Sweep

!"#$%&'$()#$$!"#$#%&'&"()
"$*
*+
,&$-.(/
!"#$%&'$()#$$
+&%""$( !"+&%""$(
),!"(-.,-/$
#$%&'$(
,/0$&.+-+&%""$(
),#-"$*-#$%&'%/1$-,/0$&.+
#$%&'$(
*+
0%(1'#&$-.(/
!"#$%&'$()#$$
+&%""$(
2131$#'"(#.4
"()-$((15'6' !
!"#$%&'$(

einfach, vollständig (keine memory leaks)
zwei Läufe über den Heap erforderlich
kann zu starker Fragmentierung des Speichers führen
Lokalität so schlecht wie bei naïver manueller Verwaltung
Objekte gleichen Alters in völlig unterschiedlichen Speicherbereichen
braucht zusätzlichen Speicher (unscanned/scanned Listen)
kann mit Tricks verhindert werden
34
Mark-and-Sweep: Analyse

Mark-and-Compact
Idee: verschieben erreichbarer Objekte an Beginn des Heaps
Zwei Phasen“stop-the-world”Algorithmus
erst markieren aller vom Root Set erreichbaren Objekte (mark)
dabei berechne für jedes Objekt Adresse im kompaktierten Heap
dann verschieben der erreichbaren Objekte & Verweise (compact)
Datenstrukturen:
free: Heap-Pegel nach Kompaktierung der bisher erreichten Objekte
scanned: Erreichte und verarbeitete Objekte + newAddress
35

Mark-and-Compact
36
free
free

Mark-and-Compact
37
free
free

Mark-and-Compact
38
free
free

Mark-and-Compact
39
free
free
free

einfach, vollständig (keine memory leaks)
bessere Lokalität als bei mark-and-sweep, keine Fragmentierung
mindestens zwei Läufe über den Heap erforderlich
compact Lauf deutlich langsamer als sweep Lauf
braucht ebenfalls zusätzlichen Speicher (unscanned/scanned Listen)
40
Mark-and-Compact

Stop-and-Copy Semispace
Idee: Ein-Phasen Verschieben durch Kopieren in reservierten Bereich
teile Speicher in zwei“Teilräume”ein (From- und To-Space)
Durchlaufe die Erreichbaren Objekte
sobald ein Objekte erreicht wird kopiere in To-Space
wenn alle erreichbaren Objekte verarbeitet, vertausche From- und To-Space
Datenstrukturen:
newAddress: Neue Adresse eines verarbeiteten Objekts
scanned: Erreichte und verarbeitete Objekte + newAddress
41

42
TOSPACE
ROOT
SET
FROMSPACE

43
TOSPACE
ROOT
SET
FROMSPACE

A B
Scan Free
C
v)
A B
Scan Free
i)
ii)
iii)
iv)
A B
Scan Free
C
D
A B
Scan Free
C D E
A B
Scan Free
C D E F
A B
Scan Free
C
A
C D
E
F
B
Scan Free
A
B
ROOT
SET
i)
ii)
iii)
iv)
A B
Scan Free
C
D
Cheney Algorithm
Kopieren mit Breitensuche
Datenstrukturen:
newAddress
scanned & unscanned fallen weg

nur ein Lauf über den Heap erforderlich
kaum zusätzlichen Speicher (Cheney)
bessere Lokalität als bei mark-and-sweep, keine Fragmentierung
immer noch“stop-the-world”Algorithmus
halber Speicher bleibt ungenutzt
45

46

➍
Partitionierende GC Algorithmen
Inkrementelle & Generationelle

49
Garbage Collectors
Reference
Counters
Trace
Based
Markand
Sweep
Markand
Compact
Incremental Partial
Generational Train
➃ Partitionierende GC Algorithmen

Inkrementelle Garbage Collection
Idee: garbage collection parallel zu Programmausführung
immer wenn Daten unerreichbar werden, gleich freigeben
Idee: trace-based wie Mark-and-… aber
Objekte die einmal scanned sind werden nicht mehr erneut betrachtet
Jedes Objekt ist immer gerade:
scanned: erreichte und verarbeitete
unscanned: erreicht, aber noch nicht verarbeitetet
unreached: noch nicht erreicht, aber erreichbar
unreachable: unerreichbar
50

51
I. Incremental GC
s GC with mutator action to reduce pause time
Ideal = (R ! New) " Lost
(R ! New) " Lost # Answer # (R ! New)
data
scanned
unscanned
unreached
tor
new
unreachable
R (reachable)
ideal
lost
mes
run
ator
I. Incremental GC
• Interleaves GC with mutator action to reduce pause time
kinds of data
scanned
unscanned
unreached
after the mutator
new
unreachable
R (reachable)
ideal
lost
resumes
has run
before mutator

52
Before After
A
B C
D
B C
D
A

• All reaching pointers are found in “scanned objects”
• Requires the occurrence of a 3-step sequence in the mutator:
Scanned
Unscanned /
Unreached Unreached
0. after a stage of GC
A B C
1. Load p = ptr from B to C
3. Store new pointer in B,
2. Store p in A
overwriting value p
pp
p

anced Compilers 7 L15: Advanced Garbage Collec
• Intercept p in any of the three-step sequence
• Treat pointee of p as “unscanned”
Scanned
Unscanned /
Unreached Unreached
0. after a stage of GC
A B C
1. Load p = ptr from B to C
3. Store new pointer in B,
2. Store p in A
overwriting value p
pp
p
Read barrier: remember all loads of pointers from B ! C
Write barrier: remember all stores of pointers A ! C
Overwrite barrier: remember all overwrites of pointer B ! C

Write Barrier am effizientesten
wird seltener aktiv als Read Barrier
weniger starke Approximation als Over-write Barrier (weniger irrtümlich
reached Objekte)
Optimierung: alloziere Objekte als white/unreachable → short-lived
kein“stop-the-world”effect
verwenden Speicher während der gesamten Laufzeit
nur konservative Approximation aus Effizienzgründen
55

Generationelle Garbage Collection
Grundidee: Partitioniere Objekte in stable und target Mengen
GC nur auf Objekten in target Objekten
Root Set für target := allgemeines Root Set + Verweise aus stable
dazu: Schreibzugriﬀe auf stable abfangen
56
II. Partial GC
• Reduces pause time by collecting only objects in the target area:
Stable set
Target set
ignore
used in tracing
ignore
include in root set

Root Set(i) := Root Set(Program) + Zeiger von j to i mit j > i
GC für Generation i falls Heap-Space für diese Generation verbraucht
58
Generational GC
bservation: objects die young
• 80-98% die within a few million instructions
or before 1 MB has been allocated
enerational GC: collect newly allocated objects more often
h generation
targetstable
1st 2nd 3rd 4th
remembered
sets

59
Younger Generation
Older Generation
ROOT
SET
Younger Generation
Older Generation
ROOT
SET
Semispace Stop-and-Copy

60
Second
Generation
Memory
First (New)
Generation
Memory
Semispace Stop-and-Copy

Wie deﬁnieren wir eine Generation?
Objekt o von i nach i+1 bei jedem Traversieren im GC von i auf o?
schnell, geringer Overhead; aber: Objekte“altern”zu schnell
z.B.: bei jedem zweiten Traversieren
hängt auch von Zahl der Generationen ab
viele Generationen = häuﬁger“altern”
61

percent surviving
never copied
percent surviving
until scavenge 2
-/
percent surviving
until scavenge 3
J’
COpid twice (advanced to next generation)1
-1
scavenge 0 scavenge 1 scavenge 2 scavenge 3
Time of data allocation
FIGURE 2b. Copying cost with two-scavenge advancement threshold

0 10 20 30 40 50 60 70 80 90 100
null
compress
db
jack
javac
jess
mpegaudio
mtrt
bh
bisort
em3d
health
mst
perimeter
power
treeadd
tsp
voronoi
ipsixql
jigsaw
nfc
xalan
average
Shortlived
Longlived
Quasi immortal
Truly immortal
(a) In percent of all allocated objects.
Table 3: Escap
jects). The nu
jects where the
Benchmark
null
compress
db
jack
javac
jess
mpegaudio
mtrt
bh
bisort
em3d
health
mst
perimeter
power
treeadd
tsp
voronoi
ipsixql
jigsaw
nfc
xalan
average
Figure 2(a) show
only shows data
From Figure 2

0 10 20 30 40 50 60 70 80 90 100
null
compress
db
jack
javac
jess
mpegaudio
mtrt
bh
bisort
em3d
health
mst
perimeter
power
treeadd
tsp
voronoi
ipsixql
jigsaw
nfc
xalan
average
Shortlived
Longlived
Quasi immortal
Truly immortal
(a) In percent of all allocated objects.
0 10 20 30 40 50 60 70 80 90 100
1
10
100
1000
10000
100000
10MB 20MB
SCCsize[objects]
Figu
Column “Write b
the write barrier for
timing data for jigsa
Write barrier overh
(v2.0.2) FastSemisp
machine. The write
store buﬀer. Becaus
programming langu
of the application,

o1
o2
o4
o3
o5
o6
o7
o8
p1
p2
p3
ure 1: Example partitioning. Solid boxes are
ects, solid arrows are pointers, dashed ovals are
titions, and dashed arrows are partition edges.
Partial GC
partial garbage collection is a GC of only a portion
he heap, such as when one or more young generations
collected in a generational collector.2
Because they do
examine the entire heap, partial GCs usually take less
related, but different, term is incremental GC. Partial
r global variable that
h m(o) ∈ C, color that
in topological order:
bject,
ith m(o) = q.
field of o that points to
olor that object gray.
n q.
ch partition q ∈ C in
sures that C is closed
opological order guar-
a partition q, all prede-
been visited.
ly the unreachable ob-
this choice: the estimator estimates how many o
dead and live in each partition, and the chooser
set of partitions where, based on the estimates,
to collect a sufficient amount of garbage at low c
The task of the estimator is to annotate each
p ∈ P with two integers dead(p) and live(p) as
Figure 2.
p1
p2
p3
p4
p5
dead(p) : live(p)
1:12
6:3
10:3
2:2
4:3

67
Garbage Collectors
Reference
Counters
Trace
Based
Markand
Sweep
Markand
Compact
Incremental Partial
Generational Train

Literatur zur Interprozeduralen Zeigeranalyse
Basiswissen:
Aho, Lam, Sethi, Ullman: “Compilers”, 2nd Edition, Kapitel 7.5–7.7
Weiterführende Literatur:
Wilson, P. R. 1992. Uniprocessor Garbage Collection Techniques. In Proc.
International Workshop on Memory Management (September 17 - 19, 1992).
Y. Bekkers and J. Cohen, Eds. Lecture Notes In Computer Science, vol. 637.
Springer-Verlag, London, 1-42.
69
Fragen

Garbage Collection

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (6)

Garbage Collection