1
Tuning Garbage Collection in an Embedded Java Environment
G. Chen, R. Shetty,
M. Kandemir,
N. Vijaykrishnan, M. J. Irwin
Microsystems Design Lab
The Pennsylvania State University
M. Wolczko
Sun Microsystems, Inc.
2
Objectives
Investigate the role of GC in energy consumption of energy-aware systems
Find energy consumption improvements based on GC mechanism
3
Roadmap
Background & Motivation KVM GC and Parameters Experiments setup Energy Characterization and
Optimization Conclusions
4
Why Java ?
Increasing popularity of Java in portable devices.• portability• natural for web based applications
Estimated number of Java enabled devices in 2005: 721 million• cell phones, PDAs, pagers etc.
5
Characteristics of Embedded Devices
Small memory capacity Requirements of low energy
consumption more (soft real-time, long duration sessions etc.)
How to incorporate the change ? Application independent - by adapting
JVM to target requirements
6
Electrical Characteristics
Devices are required to reduce size and increase performance
Technological Solution: 10 Technology Price: higher energy consumption
7
Memory Energy Consumption
Significant part of overall energy consumption
Memory types: Banked-RAM, ROM, Cache
Characteristics: Dynamic, Leakage, Shutdown
Advances in miniaturization result in higher energy leakage
8
Why GC ?
Independent of application, impacts memory management
May be easily controlled May be used to shutdown memory
banks
9
KVM GC’S
Mark & Sweep (M&S)• Simple
M&S + Compaction (M&C)• Handles fragmentation• 2KB chunks reserved for ‘Permanent data’ not
included in GC Energy tradeoff:
• Simple wastes more memory• complicated - consumes more
10
More on M&C
Compaction occurs• No big enough entry in free list• When a need for more permanent memory
arises Until compaction - garbage-occupied
memory is considered live
11
Memory Wasted Waiting for GC
12
Experiment Setup - “Hardware”
microSparc-IIep embedded processor 100Mhz, 32bit, 5-stage pipeline On chip memories: ROM, RAM, Cache
13
Experiment Energy Models
Simulate KVM executing applications Accurately simulate hardware energy
consumption Cache modeled as SRAM Scale parameters to 10 Technology Assume large leakage-energy
14
Experiment Setup - Banked Memory
Assume shutdown and turn-on capability of 16KB banks
Simulate Turn-on cost (350 cycles)
15
Experiment Setup - Benchmarks
16
Experiment Setup - Benchmarks
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
Cal
cula
tor
Cry
pto
Dra
go
n
Eli
te
Ksh
ape
Kvi
deo
Kw
ml
Man
ybal
ls
Mat
hF
P
Min
i
Mis
sile
s
Sch
edu
ler
Sta
rcru
iser
Sys
tem
En
erg
y B
reak
do
wn
Core heap(leakage) heap(dynamic)
Runtime Stack(leakage) Runtime Stack(dynamic) ROM(leakage)
ROM(dynamic)
17
Introducing Mode Control
Shutting down unused memory banks Implemented on heap and stack
The price - the turning on / off process, is negligible
18
Impact of Mode Control (M&S)
0
10
20
30
40
50
60
70
80
90
100
Cal
cula
tor
Cry
pto
Dra
go
n
Eli
te
Ksh
ape
Kvi
deo
Kw
ml
Man
ybal
ls
Mat
hF
P
Min
i
Mis
sile
s
Sch
edu
ler
Sta
rcru
iser
% E
ner
gy
Heap Runtime Stack
19
Increasing Frequency of GC
Until garbage collection, memory banks might be on only storing garbage
Increasing GC Frequency will help get rid of the garbage more quickly
Tradeoff:Energy saved versus Energy spent on GC
20
Controlling GC Frequency
In the experiment: “After K calls to the allocator”
In real implementation the policy should be f(memory allocated), or simply before turning on a new memory bank.
21
Impact of GC Frequency
0
10
20
30
40
50
60
70
80
90
100C
alcu
lato
r
Cry
pto
Dra
go
n
Eli
te
Ksh
ape
Kvi
deo
Kw
ml
Man
ybal
ls
Mat
hF
P
Min
i
Mis
sile
s
Sch
edu
ler
Sta
rcru
iser
% H
eap
En
erg
y
10 40 75 100 250 Out of MemoryMode Control
22
The Cost of Increasing GC Freq
0
20
40
60
80
100
120
140
160
180
200
Cal
cula
tor
Cry
pto
Dra
go
n
Eli
te
Ksh
ape
Kvi
deo
Kw
ml
Man
ybal
ls
Mat
hF
P
Min
i
Mis
sile
s
Sch
edu
ler
Sta
rcru
iser
% R
OM
En
erg
y
Mode Control 10 40 75 100 250
23
GC Frequency - Conclusions
Dependent on memory usage scheme Don’t exaggerate ! Frequency of ~70 gives good results Application dependently determining the
GC frequency could be an optimal(the article is already published...)
24
Modifying Object Allocation Style
M&S algorithms maintain a ‘free list’ More energy sensitive schemes: Active Bank
• free list per block• Allocate first from active banks
Active Bank+• If cannot allocate from an already active
bank - run GC
25
Impact of Object Allocation Style
0
10
20
30
40
50
60
70
80
90
100
Cal
cula
tor
Cry
pto
Dra
go
n
Eli
te
Ksh
ape
Kvi
deo
Kw
ml
Man
ybal
ls
Mat
hF
P
Min
i
Mis
sile
s
Sch
edu
ler
Sta
rcru
iser
% H
eap
En
erg
y
First Active Active+GCMode Control
26
Impact of Object Allocation Style Explained
Active Bank ~ Mode Control• Coherent with observation that the younger
die first• ‘Permanent’ objects occupy the lower part
of heap. The higher part is usually cleaned during GC
27
Impact of Object Allocation Style Explained
Active Bank + is better• Increases frequency of GC• reduces probability of turning on a new
memory bank• Permanent objects are likely to be
allocated more densely
28
Compaction
Compaction may decrease number of active memory banks
Tradeoff:Energy spent on compaction versusreduction of memory energy consumption
29
Impact of Default Compaction
0
10
20
30
40
50
60
70
80
90
100C
alcu
lato
r
Cry
pto
Dra
go
n
Eli
te
Ksh
ape
Kvi
deo
Kw
ml
Man
ybal
ls
Mat
hF
P
Min
i
Mis
sile
s
Sch
edu
ler
Sta
rcru
iser
% H
eap
En
erg
y
No Compact Compact
30
Impact of Default Compaction
Disappointing... Better compaction schemes ?
• M&C+ Perform compaction after each GC• M&C2 Different compaction algorithm
M&C2 versus M&C• cheaper marking and updating• more overhead per allocation
31
Impact of Compaction Schemes
0
10
20
30
40
50
60
70
80
90
100
Cal
cula
tor
Cry
pto
Dra
go
n
Eli
te
Ksh
ape
Kvi
deo
Kw
ml
Man
ybal
ls
Mat
hF
P
Min
i
Mis
sile
s
Sch
edu
ler
Sta
rcru
iser
% H
eap
En
erg
y
Mode Control M&C M&C2 M&C+
32
Impact of Compaction - Conclusions
Compaction does not achieve great savings
Compaction though cannot be omitted• more memory will be needed for
application due to fragmentation
33
Impact of Cache
Reduces access to main memory:• Heap energy drops to 23% of overall
energy Cache itself is a significant energy
consumer
34
Impact of GC Schemes in Presence of Cache
15%
28%
35
Conclusions
The combination of hardware mechanisms to lower energy leakage and software controlling it, may substantially reduce energy consumption
Saving may be achieved without application awareness
36
Conclusions
GC mechanisms, with minor modifications, can help reach the energy saving goal
Mode Control, Allocation strategy, GC frequency are the most important.
Compaction is usually necessary, its implementation affects energy consumption
