1. 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

2. 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

3. 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

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

5. 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

6. 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

7. 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

8. 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 – 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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 (Energy, μJ) X1 (Num. of nodes) 1 2 3 4 5 6

15. 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

16. 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

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

18. Evaluation: Computation 1234567891011 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

19. Evaluation: Infrastructure Error rates with respect to the number of simultaneously running components Error Rate = (estimated cost – actual cost) *100 / actual cost

20. 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

21. Evaluation: Overall Energy Cost Cont. Error Rate = (estimated cost – actual cost) *100 / actual cost

22. 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