Component-Level Energy Consumption
Estimation for Distributed Java-Based
Software Systems
Chiyoung Seo
Sam Malek
Nenad Medvidovic
Yahoo!
George Mason University
University of Southern
California
Motivation
 Newly emerging computing platforms
(sensors, PDAs, cell phones, etc.)
– Limited battery resources
Host 1 (battery capacity: 21700 J)
- AL (Alarm Logger)
- LSIM (Local Sensor Information Management)
- FAR (Fire Alarm Receiver)
...
LSIM
 There is a pressing need for energyefficient software systems
 If we could estimate a software
system’s energy consumption at the
level of its constituent components,
we could take appropriate actions to
prolong the system’s life-span
– Offload least important components
– Redeploy highly energy-intensive
components
– Adapt the quality of the components
FAR
Sensors
AL
GSIM
IAR
LSIM
Host 3 (battery capacity: 37500 J)
FAA
IAA
- GSIM (Global Sensor Information Management)
- IAR (Intrusion Alarm Receiver)
- LSIM (Local Sensor Information Management)
Host 2 (battery capacity: 48500 J)
- FAA (Fire Alarm Analyzer)
- IAA (Intrusion Alarm Analyzer)
Distributed sensor application
running on 3 hosts
Component-Level Energy Consumption
Estimation for Distributed Java-Based
Software Systems
Chiyoung Seo
Sam Malek
Nenad Medvidovic
Yahoo!
George Mason University
University of Southern
California
Outline
 Approach
 Framework
– Computational Energy
– Communication Energy
– Infrastructure Energy




Construction-Time Estimation
Run-time Estimation
Evaluation
Conclusion
Overall Approach
 Energy consumption of a software
component
– Computational energy cost
H2
H3
JVM P2
JVM P3
C2
C6
C7
C4
C5
• CPU processing, memory & I/O operations
C3
– Communication energy cost
• Data exchange among software
components over the network
 Infrastructure energy overhead
C1
– Operating system managing the execution
of a JVM process
– JVM’s Garbage collection thread
JVM P1
H1
7
systemEC 
  compEC(ci )  commEC(ci ) 
i 1
Computational and communication energy
costs of all the components
JVM P4
H4
4

infraEC( p j )
j 1
Infrastructure energy overhead of
all the JVM processes
Computational Energy Cost
 Focus on a component’s constituent
interfaces in modeling its energy
consumption
– More accurately estimate the energy cost
of a software component
C2
C3
I1
I2
C1
…
In
compEC (c1 ) 
i 1 j 1
C6
C7
H3
n mi
 iCompEC ( Ii , j)
H2
H1
n : total # of interfaces for a component c1
mi : total # of invocations for an interface I i
iCompEC ( I i , j ) : computational energy consumption due to each invocation of I i
C4
C5
H4
Computational Energy Cost Cont.
 255
  m

iCompEC ( I i , j )  
bNumk , j  bECk   
fNuml , j  fECl   mNum j  Emonitor

 

 k 0
  l 1





Energy cost of executingEnergy cost of executing
Energy
allcost of executing all
all the bytecodes
the native methods the monitor operations
bNumk , j : # of times that each bytecode type k is executed during the invocation
bECk : Energy consumption of executing each bytecode type k
fNuml , j : # of times that each native method l is executed during the invocation
fECl : Energy consumption of executing each native method l
mNum j : # of the monitor operations executed during the invocation
Emonitor : Energy consumption for a monitor operation
class Stack {
int[] data;
int top;
public Stack(int size)
{
data = new int[size];
top=0;
}
public short synchronized push(int i)
{
if(top == data.length)
return 0;
data[top] = i ;
top++;
return 1;
}
…
}
A sequence of bytecodes and monitor operations
executed per push invocation:
- Monitor acquisition (energy cost: 5.4047 μJ)
- getfield: loading the value of a field (top) into an operand
stack (energy cost: 4.5098 μJ)
- getfield: loading the value of a field (data.length) into
an operand stack (energy cost: 4.5098 μJ)
- if_icmpeq: comparing a top value with a data.length value
(energy cost: 3.7744 μJ)
- iload: loading a local integer variable i into an operand stack
(energy cost: 3.1384 μJ)
- iastore: storing a local variable i into an integer array data
(energy cost: 3.5786 μJ)
- getfield: loading the value of a field (top) into an operand
stack (energy cost: 4.5098 μJ)
- iadd: adding 1 into the loaded value (energy cost: 2.9485 μJ)
- putfield: storing the added value into a field (top)
(energy cost: 4.6758 μJ)
- return: terminating push method by returning a value
(energy cost: 3.8454 μJ)
- Monitor release (energy cost: 5.3064 μJ)

Energy consumption of each type of bytecode and native method

Energy consumption of a monitor operation
iCompEC ( push)  monitor operations + 3  getfield  iload  iastore  if_icmpeq  iadd  putfield  return
– Execute a class file that executes each bytecode (or native method) type repeatedly
 46.2  J
– Execute a class file invoking a method that should be synchronized among multiple threads

This measurement is just an one-time effort
Communication Energy Cost

Target network environment is LAN (or
WLAN) consisting of dedicated routers
and either stationary or mobile hosts
C2
C3
I1
H2
I2
C1
n
commEC (c1 ) 
In
mi

…
n : total # of interfaces for a component c1
mi : total # of invocations for an interface I i
iCommEC ( I i , j ) : communication energy consumption
due to each invocation of I i
C7
H3
iCommEC ( I i , j )
i 1 j 1
C6
H1
C4
C5
H4
Communication Energy Cost Cont.
 Modeling the communication cost based on UDP
– UDP is a much more lightweight protocol than TCP  frequently used
in embedded resource constrained settings

 
iCommEC ( I i , j )  tEvtSizec1 ,c2  tECH1  tS H1  rEvtSizec1 ,c2  rECH1  rS H1
Transmission energy cost

Receiving energy cost
tEvtSize : Size of a transmitted message on a host H1 during the jth invocation
tECH1 : Energy cost (Joule / byte) on a host H1 due to sending a unit of data
tS H1 : Constant energy cost (Joule) on a host H1 incurred by device state changes
and channel acquisition while sending data
rEvtSize : Size of a received message on a host H1 during the jth invocation
rECH1 : Energy cost (Joule / byte) on a host H1 due to receiving a unit of data
rS H1 : Constant energy cost (Joule) on a host H1 incurred by device state changes
and channel acquisition while receiving data
Infrastructure Energy Cost
 For each JVM process p, there is an additional energy
overhead due to
– Garbage collection
• During the garbage collection, all threads except a GC thread within a
JVM process stop temporarily
• Energy consumption is directly proportional to the time spent by a GC
thread
– Implicit OS routines invoked for managing a JVM process
• Context switching (including process rescheduling), page faults, page
reclaims
• Energy consumption is directly proportional to the number of implicit
OS routines executed

 
 
 
infraEC ( p )  tGC p  gEC  csNum p  csEC  pfNum p  pfEC  prNum p  prEC
Energy cost of
Energy
a GC cost of processing Energy
all the cost of processing all the
thread
context switches
page faults and reclaims

Construction-Time Estimation
 Classify each component’s interfaces into one of the
three different types
– Type I interface: the amount of computation required is
constant regardless of its input parameters’ values
• E.g., setTime interface of a Clock component
– Type II interface: the amount of computation required is a
function of input parameters’ size or values
• E.g., encrypt interface of an Encryption component
– Type III interface: the amount of computation required is
not a function of input parameters’ size or values
• E.g., query interface of a Database component
Construction-Time Estimation:
Type I and II
 Computational energy cost of Type I interface
– Generate an arbitrary input
– Calculate the computational cost of the arbitrary input
 Computational energy cost of Type II interface
– Generate a set of sample inputs and calculate the
computational energy cost of each input
– Run multiple regression on a set of inputs and their energy
costs for getting an energy equation
Multiple Regression for find Interface of
Shortest-Path Component
Y (Energy, μJ)
Y (Energy, μJ)
6
5
4
3
2
1
X2 (Num. of edges)
Point 1
Point 2
Point 3
Point 4
Point 5
Point 6
122688
245395
364891
215760
316622
710709
Estimated (J) 119767
261905
351300
224201
341570
677319
Actual (J)
Construction-Time Estimation: Type III
 Type III interface with finite execution paths
– Generate a set of inputs covering all the execution paths by
using symbolic execution
– Calculate the computational energy cost of each input (each
execution path)
 Type III interface with infinite execution paths
– If the expected range of inputs is known,
• Calculate the computational energy cost of each input
– Otherwise,
• Generate a set of sample inputs and calculate the average computational
energy cost per invocation
Runtime Estimation
 Type I interface
– Same as construction-time estimate
 Type II interface
– Monitor the input value of each invocation
– Find the computational energy cost of each invocation
from the energy equation generated by multiple regression
 Type III interface
– Monitor the amount of computation for each invocation
– Calculate the computational energy cost of each invocation
Experimental Setup
Power Supply
PDA (iPAQ)
Digital
Multimeter
Data Collection
Computer
Java
Components
Measurement Setup
 iPAQ 3800 handheld device running Linux and Kaffe 1.1.5 JVM
 HP 3458-a digital multimeter for measuring the current drawn
by iPAQ
 Data collection computer controls the digital multimeter and
reads the current samples from it
Evaluation: Computation
Error Rate = (estimated cost – actual cost) *100 / actual cost
6
Error rate (%)
4
2
0
1
2
3
4
5
6
7
8
9
10
11
-2
-4
-6
1
2
3
4
5
6
7
8
9
10
11
SHA
MD5
IDEA
Median
Filter
LZW
Sort
Jess
DB
Shortest
path
AVL
Linked
List
 Evaluated a large number of open-source Java components with
various characteristics
 Computational, memory, and communication intensive
Evaluation: Infrastructure
Error Rate = (estimated cost – actual cost) *100 / actual cost
4
Error rate (%)
2
0
2
4
6
8
10
-2
-4
-6
Number of simultaneously running components
Error rates with respect to the number of
simultaneously running components
Evaluation: Overall Energy Cost
Error Rate = (estimated cost – actual cost) *100 /
actual6 cost
DB
Server
IDEA
iPAQ (host A)
IDEA
FTP
Client
2
0
1.1
2.1
3.4
4.2
5.1
7.3
9.5
-2
-4
Wireless
router
-6
iPAQ
(host C)
FTP
Server
Frequency (times/sec)
IDEA
3
LZW
Distributed software system
consisting of three hosts
2
Error rate (%)
LZW
DB
Client
Error rate (%)
4
iPAQ
(host B)
1
0
3.3
6.2
12.2
18.3
-1
-2
-3
Avg. size of a message (KB)
24.4
Evaluation: Overall Energy Cost Cont.
Error Rate = (estimated cost – actual cost) *100 / actual cost
4
3
Error rate (%)
2
1
0
-1
-2
-3
-4
-5
3 hosts, 8
components
5 hosts, 17
components
7 hosts, 25
components
9 hosts, 33
components
Conclusion
 A framework for estimating a distributed Java-based software
system’s energy cost
 Unlike previous approaches, the framework provides fine-grained
energy estimates for each software component in terms of its
public interface
 Our evaluation indicates that the energy estimates come within
5% of the actual energy consumption
 Construction-time
– Can be used to make appropriate design and configuration decisions
 Run-time
– Energy estimates can be refined further
– Can be used to manage the energy consumption of the system through
dynamic reconfiguration