Component-Level Energy Consumption Estimation for Distributed Java-Based Software Systems

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

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 applicationrunning on 3 hosts

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

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

5. Overall Approach H2 H3 • 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 JVM P2 JVM P3 C2 C3 C6 C7 C1 C4 C5 JVM P1 JVM P4 H4 H1 Computational and communication energy costs of all the components Infrastructure energy overhead of all the JVM processes

6. Computational Energy Cost C2 C3 H2 I1 C1 I2 C6 … In C7 H3 H1 C4 C5 H4 • Focus on a component’s constituent interfaces in modeling its energy consumption • More accurately estimate the energy cost of a software component

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. 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) 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; } … } • 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 C2 C3 H2 I1 C1 I2 C6 … In C7 H3 H1 C4 C5 H4 • Target network environment is LAN (or WLAN) consisting of dedicated routers and either stationary or mobile hosts

10. 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 Transmission energy cost Receiving energy cost

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., encryptinterface 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 6 Y (Energy, μJ) 5 Y (Energy, μJ) 4 3 2 1 X1 (Num. of nodes) X2 (Num. of edges) Point 1 Point 2 Point 3 Point 4 Point 5 Point 6 Actual (J) 122688 245395 364891 215760 316622 710709 Estimated (J) 119767 261905 351300 224201 341570 677319

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 Power Supply DigitalMultimeter PDA (iPAQ) Data CollectionComputer JavaComponents Measurement Setup

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

20. Evaluation: Overall Energy Cost Error Rate = (estimated cost – actual cost) *100 / actual cost iPAQ (host B) IDEA DBServer iPAQ (host A) IDEA DBClient Wirelessrouter iPAQ(host C) LZW FTPClient IDEA FTPServer LZW Distributed software system consisting of three hosts

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