component-level energy consumption estimation for distributed java-based software systems sam malek...

22
Component-Level Energy Consumption Estimation for Distributed Java-Based Software Systems Sam Malek George Mason University Chiyoung Seo Yahoo! Nenad Medvidovic University of Southern California

Upload: shanon-ferguson

Post on 27-Dec-2015

217 views

Category:

Documents


0 download

TRANSCRIPT

Component-Level Energy Consumption Estimation for Distributed Java-Based

Software Systems

Sam MalekGeorge Mason

University

Chiyoung SeoYahoo!

Nenad MedvidovicUniversity of Southern

California

Motivation Newly emerging computing

platforms (sensors, PDAs, cell phones, etc.)– Limited battery resources

There is a pressing need for energy-efficient 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

Host 1 (battery capacity: 21700 J) - AL (Alarm Logger) - LSIM (Local Sensor Information Management) - FAR (Fire Alarm Receiver)

Host 3 (battery capacity: 37500 J) - 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)

Sensors

...LSIM

FAR AL

FAA IAA

IAR

LSIM

GSIM

Distributed sensor application

running on 3 hosts

Component-Level Energy Consumption Estimation for Distributed Java-Based

Software Systems

Sam MalekGeorge Mason

University

Chiyoung SeoYahoo!

Nenad MedvidovicUniversity of Southern

California

Outline

Approach Framework

– Computational Energy– Communication Energy– Infrastructure Energy

Construction-Time Estimation Run-time Estimation Evaluation Conclusion

7 4

1 1

( ) ( ) ( )i i ji j

systemEC compEC c commEC c infraEC p

Computational and communication energy costs of all the components

Infrastructure energy overhead of all the JVM processes

H1

H2 H3

H4

C1

JVM P2

C2 C3 C6 C7

C4 C5

JVM P3

JVM P1 JVM P4

Overall Approach Energy consumption of a software

component– Computational energy cost

• CPU processing, memory & I/O operations

– Communication energy cost• Data exchange among software

components over the network

Infrastructure energy overhead– Operating system managing the execution

of a JVM process– JVM’s Garbage collection thread

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

11 1

1

( ) ( , )

: total # of interfaces for a component

: total # of invocations for an interface

( , ) : computational energy consumption due to each invocation of

imn

ii j

i i

i

compEC c iCompEC I j

n c

m I

iCompEC I j

iI

H1

C1 …

I1

I2

In

C4

C2

C6

C3

C5

C7

H2

H3

H4

Computational Energy Cost Cont.

255

, ,0 1

,

( , )

: # of times that each bytecode type is executed during the invocation

: Energy consumption of executing e

m

i k j k l j l j monitork l

k j

k

iCompEC I j bNum bEC fNum fEC mNum E

bNum k

bEC

,

ach bytecode type

: # of times that each native method is executed during the invocation

: Energy consumption of executing each native method

: # of the monitor operations executed

l j

l

j

k

fNum l

fEC l

mNum during the invocation

: Energy consumption for a monitor operationmonitorE

Energy cost of executing all the bytecodes

Energy cost of executing all the native methods

Energy cost of executing all the monitor operations

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)

( ) operations + 3 _

46.2

iCompEC push monitor getfield iload iastore if icmpeq iadd putfield return

J

Energy consumption of each type of bytecode and native method– Execute a class file that executes each bytecode (or native method) type repeatedly

Energy consumption of a monitor operation– 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

11 1

1

( ) ( , )

: total # of interfaces for a component

: total # of invocations for an interface

( , ) : communication energy consumption

imn

ii j

i i

i

commEC c iCommEC I j

n c

m I

iCommEC I j

due to each invocation of iI

Target network environment is LAN (or WLAN) consisting of dedicated routers and either stationary or mobile hosts

H1

C1 …

I1

I2

In

C4

C2

C6

C3

C5

C7

H2

H3

H4

Communication Energy Cost Cont.

1 2 1 1 1 2 1 1

1

, ,

1

1

( , )

: Size of a transmitted message on a host during the th invocation

: Energy cost ( / ) on a host due to sending

i c c H H c c H H

H

iCommEC I j tEvtSize tEC tS rEvtSize rEC rS

tEvtSize H j

tEC Joule byte H

1 1

1

a unit of data

: Constant energy cost (Joule) on a host incurred by device state changes

and channel acquisition while sending data

: Size of a received message on a host durin

HtS H

rEvtSize H

1

1

1

1

g the th invocation

: Energy cost ( / ) on a host due to receiving a unit of data

: Constant energy cost (Joule) on a host incurred by device state changes

and channel acq

H

H

j

rEC Joule byte H

rS H

uisition while receiving data

Transmission energy cost Receiving energy cost

Modeling the communication cost based on UDP

– UDP is a much more lightweight protocol than TCP frequently used in embedded resource constrained settings

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

( )

: time (sec) that the GC thread is active during the execution of a JVM process

: average energy consumption rate (Joule/sec) of the GC t

p p p p

p

infraEC p tGC gEC csNum csEC pfNum pfEC prNum prEC

tGC p

gEC

hread

: # of context switches occurred during the execution of process

: energy consumption (Joule) of processing a context switch

: # of page faults occurred during the execution of pr

p

p

csNum p

csEC

pfNum ocess

: energy consumption of processing a page fault

: # of page reclaims occurred during the execution of process

: energy consumption of processing a page reclaim

p

p

pfEC

prNum p

prEC

Energy cost of a GC thread

Energy cost of processing all the context switches

Energy cost of processing all the 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

Estimated (J)

Actual (J)

119767

122688

Point 1

261905

245395

Point 2

351300

364891

Point 3

224201

215760

Point 4

341570

316622

Point 5

677319

710709

Point 6

X2 (Num. of edges)

Y (

En

erg

y,

μJ

)

Y (

En

erg

y,

μJ

)

X1 (Num. of nodes)

1

2

3

4

5

6

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

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

JavaComponents

PDA (iPAQ)

Power SupplyDigital

MultimeterData Collection

Computer

Measurement Setup

Evaluation: Computation

-6

-4

-2

0

2

4

6

1 2 3 4 5 6 7 8 9 10 11

Err

or

rate

(%

)

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

Error Rate = (estimated cost – actual cost) *100 / actual cost

Evaluated a large number of open-source Java components with various characteristics

Computational, memory, and communication intensive

Evaluation: Infrastructure

- 6

- 4

- 2

0

2

4

2 4 6 8 10

Number of simultaneously running components

Err

or

rate

(%

)

Error rates with respect to the number of simultaneously running components

Error Rate = (estimated cost – actual cost) *100 / actual cost

Evaluation: Overall Energy Cost

DBClient

iPAQ (host A)

Wirelessrouter

iPAQ (host B)

iPAQ(host C)FTP

Client

IDEA

LZW

DBServer

IDEA

FTPServer

IDEA

LZW

Distributed software system consisting of three hosts

Error Rate = (estimated cost – actual cost) *100 / actual cost

-3

-2

-1

0

1

2

3

3.3 6.2 12.2 18.3 24.4

Avg. size of a message (KB)

Err

or

rate

(%

)

-6

-4

-2

0

2

4

6

1.1 2.1 3.4 4.2 5.1 7.3 9.5

Frequency (times/sec)

Err

or

rate

(%

)

Evaluation: Overall Energy Cost Cont.

-5

-4

-3

-2

-1

0

1

2

3

4

3 hosts, 8components

5 hosts, 17components

7 hosts, 25components

9 hosts, 33components

Err

or

rate

(%

)Error Rate = (estimated cost – actual cost) *100 / actual cost

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