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

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 Distributed sensor application running on 3 hosts

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

Outline  Approach  Framework – Computational Energy – Communication Energy – Infrastructure Energy  Construction-Time Estimation  Run-time Estimation  Evaluation  Conclusion

Computational and communication energy costs of all the components Infrastructure energy overhead of all the JVM processes H1H1 H2 H2 H3 H3 H4 H4 C1C1 JVM P 2 C2C2 C3C3 C6C6 C7C7 C4C4 C5C5 JVM P 3 JVM P 1 JVM P 4 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 H1H1 C1C1 … I1I1 I2I2 InIn C4C4 C2C2 C6C6 C3C3 C5C5 C7C7 H2 H2 H3 H3 H4 H4

Computational Energy Cost Cont. 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: μJ) - getfield: loading the value of a field (top) into an operand stack (energy cost: μJ) - getfield: loading the value of a field (data.length) into an operand stack (energy cost: μJ) - if_icmpeq: comparing a top value with a data.length value (energy cost: μJ) - iload: loading a local integer variable i into an operand stack (energy cost: μJ) - iastore: storing a local variable i into an integer array data (energy cost: μJ) - getfield: loading the value of a field (top) into an operand stack (energy cost: μJ) - iadd: adding 1 into the loaded value (energy cost: μJ) - putfield: storing the added value into a field (top) (energy cost: μJ) - return: terminating push method by returning a value (energy cost: μJ) - Monitor release (energy cost: μ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 Target network environment is LAN (or WLAN) consisting of dedicated routers and either stationary or mobile hosts H1H1 C1C1 … I1I1 I2I2 InIn C4C4 C2C2 C6C6 C3C3 C5C5 C7C7 H2 H2 H3 H3 H4 H4

Communication Energy Cost Cont. Transmission energy costReceiving 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 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) Point Point Point Point Point Point 6 X2 (Num. of edges) Y (Energy, μJ) X1 (Num. of nodes)

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 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 Java Components PDA (iPAQ) Power Supply Digital Multimeter Data Collection Computer Measurement Setup

Evaluation: Computation SHAMD5IDEAMedian Filter LZWSortJessDBShortest path AVLLinked 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 Error rates with respect to the number of simultaneously running components Error Rate = (estimated cost – actual cost) *100 / actual cost

Evaluation: Overall Energy Cost DB Client iPAQ (host A) Wireless router iPAQ (host B) iPAQ (host C) FTP Client IDEA LZW DB Server IDEA FTP Server IDEA LZW Distributed software system consisting of three hosts Error Rate = (estimated cost – actual cost) *100 / actual cost

Evaluation: Overall Energy Cost Cont. 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