Generating Real-Time Profiles of Runtime Energy Consumption for Java Applications

Generating Real-Time Profiles of Runtime Energy Consumption for Java Applications Muhammad Nassar, Julian Jarrett, Iman Saleh, M. Brian Blake Department of Computer Science University of Miami Coral Gables, Florida, USA m.mansour1@umiami.edu {j.jarrett, iman, m.brian.blake}@miami.edu Abstract Energy consumption of computer-based systems is a growing concern, especially for large scaled distributed systems that operate in data centers and server farms. Currently, there exist many hardware implementations that holistically measure the consumption of energy for hardware and software systems. These approaches are limited as they measure the current power consumption of the overarching system - an approach that does not necessarily assist in making the underlying software more power-aware while under operation. This paper introduces the algorithm and process of calculating the energy consumption of Java applications at runtime. This approach is evaluated using a new energy profiler tool that is designed to integrate with a Java application leveraging the underlying physical architecture of the hardware. By incorporating the awareness of energy consumption within the software application, then that application can dynamically choose the most energy-efficient processing paths within its operations. Keywords - power consumption; java; energy; distributed systems; software profiling I. INTRODUCTION Energy consumption is a significant global challenge. Data centers and servers in the United States consume huge amounts of energy and consequently challenge the sustainability of our natural resources [8,9,10]. The use of enterprise service-oriented systems has only exacerbated the challenges [7,16]. Furthermore, on an individual basis with the prevalence of mobile devices, it is important to optimize software operations in order to extend battery capabilities. What attributes are required and which are most effective in calculating energy consumption in a runtime environment of a Java application? What are the challenges for disambiguating residual power consumption from the hardware platform with power consumed by the targeted software application? Are there approaches for reducing the amount of residual power calculated within the software application-specific calculation? To address these research questions, we introduce a unique method for profiling applications in terms of their runtime power consumption. To support this method, we conceptualized and developed a novel Energy Profiler for Java applications. The profiler integrates with Java applications in such a way that provides an energy consumption estimate for the software in question. The profiler leverages the energy model described in [1], where the authors estimate the power consumption of a computational model with N number of processors, a separate cache memory for each processor and main memory. This approach enables software developers to use energy efficiency as a key performance metric influencing their software design decisions. Moreover, software engineers will be able to abstract design practices and patterns that decrease the energy footprint of applications. We evaluate this model by comparing estimated values produced from the energy profiler with measures produce from a physical power consumption meter. Using varying programming constructs to implement the same function, we show a significant degree of accuracy with our model and implementation when comparing energy consumption trends to processing intensity. II. RELATED WORK Many frameworks have been proposed to profile power and energy consumption across different types of computer systems. These frameworks utilize both hardware and software techniques for profiling energy and target both servers and mobile devices. In the early work of one of the co-authors of this paper, a method was proposed that leveraged design-time testing of web services using generic loads of web traffic. The energy was measured during a training phase and was used to develop a model for a specific web service at various server and software states [5]. The work described in [5] and [6] uses a more predictive model applied towards the efficient power management of web services and redundantly deployed cloud environments. Some of the previous efforts in this area evaluate the overall system energy usage [11,12], while others have the capability of applying more granular measurement techniques to isolate and profile individual components. The authors in [2] introduce the PowerPak Framework; a combination of hardware and software components capable of low-level 592

energy profiling of parallel scientific applications on multicore, multi-processor distributed systems. They use physical instrumentation including sensors, meter circuits and data acquisition devices for measurement. Software components consist of drivers for physical meters, sensors, and a user level API for automated power profiling and synchronization of code. The framework is also capable of producing direct and derived measurements and isolating individual component consumption through the use of fine-grained systematic power measurements. PowerScope is a tool proposed by the authors in [3] to profile the energy usage of mobile applications through statistical sampling. A digital multi-meter is used to sample both the power consumption and system activity and passes this information to a data collection computer running the energy monitor. An energy profile is then generated and the data is analyzed offline to remove profiling overhead. In [4], researchers at Microsoft present a Windows based finegrained energy profiler by implementing and integrating a workload manager, an event logger and an energy profiler. Event tracing is started by the workload manager, which executes code under fixed loads of data. Tracing includes kernel level tracing of components such as the CPU, Disk I/O, page faults, heap range creation and context switches. The event logger simply logs all events generated by the workload manager and the energy profiler is then used to correlate system resource usage of an application. Some other efforts on the hardware level make use of Dynamic Voltage and Frequency Scaling (DVFS). DVFS is a widely used technique for power manipulation [13,15]. Its basic idea is to decrease the CPU frequency to allow a corresponding change in the supplied voltage. This in turn results in a reduction of the overall power consumption. DVFS is being used mainly to control the power consumed by the CPU cores rather than main memory. Despite this fact, the writers of [14] successfully developed a memory frequencyscaling algorithm that could reduce the power consumption of main memory by around 14% on average without any noticeable performance degradation. Unlike the previous approaches, our tool does not require the use of external instrumentation for measurement. Our approach for application profiling utilizes a plug-in that operates in real-time and produces an estimate of the total energy consumed by the application. The plug-in is provided as a JAR file that can be imported into Java applications. This approach extends the state of the art as it allows applicationlevel estimations. The profiler allows the applications to be more self-aware of their own energy signatures. We use a mathematical model that estimates the energy usage given a set of parameters describing the underlying hardware. We validate our model s accuracy by comparing the estimated values to the ones measured by an energy meter. III. ENERGY MODEL According to our model, the energy consumed by a software system has 3 main components: Computational Energy: EPI * T CPU * X Memory access energy: E m * T Active * (The amount of memory used in bytes) Leakage Energy: E l * T Active * X where, EPI is the energy consumed per CPU instruction (in the instruction set of the CPU), T CPU is the total time the CPU is active, E m is the energy consumed for a single memory access, E l is some hardware constant, T Active is the total time the system is active (including CPU idle time) and X is the CPU clock frequency. This energy model is loosely based on the one described in [1], and relies on the values obtained from the Java Virtual Machine (JVM). The computational energy component is computed as the product of the CPU frequency, the total time the CPU is active where these two terms provide the total number of instructions executed and the energy consumed per instruction, which is a chipset constant. The JVM provides the total time the CPU is active, while the user is responsible for providing the CPU frequency, and the energy per instruction value, if available. Some assumptions are made while calculating the computational energy component. The system used for testing has an Intel Core 2 mobile chipset and it is assumed that the CPU performed one instruction per cycle. It is also assumed that the microprocessor is the sole energy consumer and that other parts of the chipset like the north/southbridge is not taken into account since the energy model in [1] does not incorporate them. The Graphics Processing Unit (GPU) is not incorporated in the model either, and is not taken into account. However, the tests presented in later sections do not call for any GPU usage. As for the memory access energy, since there is no direct way of computing the exact number of memory accesses, and since the JVM provides the total amount of memory it uses directly, an approximated calculation is used as described above. The total memory access energy is calculated as the product of the amount of memory used by the JVM, the total time the application is active where these two terms provide the total amount of memory that needs to be sustained for the lifetime of the application and the energy consumed per memory access, which is also a chipset constant. The JVM provides the total amount of memory used, and the total time the application is active is calculated as the difference between the end and start times of the application obtained directly from the JVM. The user provides the energy per memory access value, if available. The leakage energy component is calculated in the exact same manner as described in [1], which is the product of the CPU frequency, the total time the application is active, and E l, which is a hardware constant value provided by the user if available. IV. DESIGN AND ARCHITECTURE An energy profiler plug-in that implements the energy model described in Section 3 was developed in Java. It is available as a JAR file which can be easily integrated into other Java applications. As shown in Figure 1, the plug-in gathers the data it needs from two sources, user input about chipset 593

specific constants and CPU and memory performance information from the JVM. The plug-in then applies this data to the energy model to produce the energy consumption information. As shown in the class diagram described in Figure 2, the application is split into three classes. The CPUMonitor class is responsible for fetching CPU utilization information from the JVM. The MemoryMonitor class gathers memory utilization information from the JVM. The EnergyCalculator class collects the data retrieved by these two components, plugs them along with the hardware constants into the energy model, and provides a total consumption estimate in Joules. The hardware constant values EPI, E m and E l are hardware-specific and should be provided by the developers. If not provided, the plug-in uses default values specific to the Intel Core 2 Duo processor architecture. In order to use the plug-in to gather energy consumption data, some steps need to be performed. Before the code block whose energy consumption needs to be analyzed, an object of type EnergyCalculator is declared and the current CPU frequency in GHz is passed as a parameter to its constructor. If the hardware constants EPI, E m and E l are known, another constructor is provided that accepts them as parameters alongside the CPU frequency. If these constants are not provided, default values are used as described earlier. After the code block that is being examined, the method PlugDataIntoModel() is called from the previously defined EnergyCalculator object. This method returns a string value that represents the energy consumed by the enclosed code block in Joules. Listing 1 shows how an EnergyCalculator class object can be used to profile the energy usage of Java code. As explained earlier, the EnergyCalculator class object has to be initialized before the code block in question and a call to the PlugDataIntoModel() method after the code block will provide the energy consumption estimate. Listing 2 shows the pseudo-code of the EnergyCalculator class. Figure 2. System Class Diagram. EnergyCalculator calc(operatingfrequency, EPI, Em, El); <Profiled Java Code> String Energy_Consumption = <calc.plugdataintomodel>; Listing 1. Energy Profiler s Usage. 594

public EnergyCalculator (CPUFrequency, EPI, Em, El) { CPUMonitor mycpumonitor; MemoryMonitor mymemorymonitor; double StartTime = <now>; double OperatingFrequency = <CPUFrequency>; double EPI = <user input or default value from Datasheet>; double Em = <user input or default value from Datasheet>; double El = <user input or default value from Datasheet>; } private void CalculateEnergyConsumption () { double memoryusage = <mymemorymonitor. GetUsedMemory()>; double cpuusage = <mycpumonitor. GetCPUUsageTime>; double EndTime = <now>; double TotalTime = <EndTime StartTime>; } public String PlugDataIntoModel() { CalculateEnergyConsumption(); double E_comp = <EPI * cpuusage * OperatingFrequency>; double E_mem = <Em * TotalTime * memoryusage * 1024>; double E_leak = <El * TotalTime * OperatingFrequency>; double TotalEnergy = <E_comp + E_mem + E_leak>; return TotalEnergy.toString(); } Listing 2. Energy Profiler s Pseudo-code. Figures 4 and 5 provide sample results illustrating the usage of the profiler. Figure 4 illustrates a comparison between the estimated energy calculated by the energy profiler and the actual readings obtained using the WattsUp meter. The test is conducted on a simple TCP implementation in Java. Figure 5 provides a similar comparison using a recursive implementation of a Fibonacci sequence calculator. As noted in Figure 4, the estimated and measured energy consumption values increased consistently with the rise in the number of packets sent. The difference between estimated and measured values increased as the load on the system increased. This difference increased from around 10% on lighter system loads to approximately 18% with the highest tested load. We anticipated a slight delta between the estimated and measured energy consumption since the energy profiler only measures the consumption of the application in question, whereas the WattsUp meter measures the entire system s consumption. Figure 5 shows that the estimated and measured values also increased consistently with the increase in the value of the Fibonacci term. This pattern demonstrates the same behavior as the one seen in Figure 4. To better understand calculated energy, we decomposed the calculation into the components defined in Section 3. The average relative contributions of computational energy, memory access energy and leakage energy are approximated to 85%, 10% and 5% for the TCP simulation application and 90%, 3% and 7% for the Fibonacci sequence calculator application. The level of contribution of each component is reasonable with respect to the results presented in the related works [17] and [18]. The obtained increase our confidence in the validity of the profiler. Within each experiment, the percentages are consistent as the load increased and the results are also consistent across different applications. Figure 3. Picture of the Watts-Up Measurement Devices. V. EVALUATION The energy profiler can be used to estimate the energy consumed by Java applications as well as compare the consumption of different implementations of the same algorithm. To validate our estimates, we compared energy consumption output from the profiler to energy consumption figures obtained from the WattsUp meter (https://www.wattsupmeters.com), a physical device that measures the real time energy consumption of electronic devices in Watts. The WattsUp meter is shown in Figure 3. Figure 4. Estimated vs. Actual Energy Readings for a Simple TCP Implementation. Figures 6, 7 and 8, illustrate the results obtained when the profiler is used to measure the energy consumption of both recursive and iterative implementations of a Fibonacci sequence calculator. 595

Figure 8. A Comparison between Recursive and Iterative Fibonacci Implementations on Ubuntu Linux 11.10. Figure 5. Estimated vs. Actual Energy Readings for a Recursive Fibonacci Implementation. Figure 6. A Comparison between Recursive and Iterative Fibonacci Implementations on Microsoft Windows 7. Figure 7. A Comparison between Recursive and Iterative Fibonacci Implementations on Mac OS X 10.8.5. The average energy consumption values for each Fibonacci term (from 25 to 55 in increments of 5) are recorded over 12 runs. The tests are repeated across three major operating systems; Microsoft Windows 7, Mac OS X 10.8.5 and Ubuntu Linux 11.10. The results for all three operating systems demonstrated the same pattern. The nature of complexities of the recursive and iterative Fibonacci implementations is evident in the graphs, where the complexity of the iterative implementation grows linearly while that of the recusrive implementation grows exponentially. The results obtained demonstrate the expected behaviors of both implementations. VI. DISCUSSION The results of our experiments demonstrate that the energy profiler tool is effective in providing estimates that compare favorably to real measurements. Although many factors are involved when it comes to measuring the energy consumed by different kinds of hardware, the profiler allows for the specification of the hardware constants EPI, E m and E l of the underlying chipset as well as the CPU operating frequency. For the sake of consistency and accuracy of the results, all of the experiments are conducted on the same hardware with no other applications running except the operating system itself. A. Estimating Energy Consumption The first of the two major functionalities of the profiler is to provide absolute estimates of the energy consumed by a certain Java application. Figures 4 and 5 illustrate how those estimates compare to real measurements. It is worth mentioning that in these figures, the energy usage estimates obtained from the profiler are actually higher than those collected by actual measurements. This would not normally be expected since the profiler measures only the energy usage of the Java application under investigation, while the WattsUp meter measures the consumption of the whole system. This could be explained by the fact that no other applications were running while the experiments were being conducted - only the application under investigation and the OS processes - and by the fact that a margin of error in the estimation is expected since many hardware factors and constants are involved in the calculation. Taking these facts and factors into consideration, 596

the difference between the estimated and actual figures is negligible on lighter levels of system load, however acceptable at the higher load levels. When it comes to measuring the absolute energy consumption values, the hardware constants described earlier in the energy model play a major role in the correct estimation. The constants that are the hardest to collect are EPI, E m and E l. These constants are chipset dependent and have to be collected form the chipset datasheet. We successfully found the values of EPI and E m for the Intel Core 2 mobile chipset, but we couldn t find an exact value for E l and its value is estimated based on information we obtained from the datasheet of a similar chipset to the one we used. The authors in [19] provide the EPI values for different Intel microprocessors. In its current form, we believe the energy model we use should provide highly accurate results as long as all the variables in the model are as accurate as possible. B. Comparing Algorithm Implementations Figures 6, 7, and 8 demonstrate how the profiler can be effective for another purpose, which is comparing different implementations of the same algorithm from the point of view of energy consumption. This could prove to be very important in real world applications as it provides the capability of comparing the energy consumption of complicated algorithms without having to analyze their complexities thoroughly. It could be considered as a black box technique of analyzing algorithms. The task illustrated (computing the Nth Fibonacci term) provides a good example of such usage. As anticipated, the recursive implementation consumed much more energy than the iterative one, especially as the load on the system increased with the increase of the value of the Fibonacci term. The results are also consistent across different platforms. The marginal error contained in the estimation technique is somewhat irrelevant when comparing different algorithms, since the magnitude of the delta between the estimations is the decisive factor for comparison, rather than the absolute figures. VII. CONCLUSION AND FUTURE WORK This paper presented the experience, method and application of creating an energy profiler tool with the ability to isolate the energy consumption of a specific Java application. Initial experimentation demonstrates that this approach and toolset compare favorably to real measurements. Future work will focus on tweaking the energy model to take into account the internal workings of the JVM, and consequently decreasing the gap between the actual and estimated values. The model can also be expanded to incorporate more hardware component, like the GPU, Video RAM and IO components. We plan to leverage the energy profiler in developing a body of work that describes energy concerns when using specific design patterns for certain types of infrastructures. We believe that this energy profiling approach at the application-level can be used as a training aid for software engineers and developers when it comes to developing sustainable software. REFERENCES [1] Agha, G. and Korthikanti, V. 2010. Towards Optimizing Energy Costs of Algorithms for Shared Memory Architectures. Proceedings of the 22nd ACM symposium on Parallelism in algorithms and architectures. pp. 157-165. [2] Ge, R., Feng, X., Song, S., Chang, H., Li, D., and Cameron, K. W. 2010. "Powerpack: Energy profiling and analysis of high-performance systems and applications." Parallel and Distributed Systems, IEEE Transactions on 21, no. 5 (2010). pp. 658-671. [3] Flinn, J. and Satyanarayanan, M. 1999. "Powerscope: A tool for profiling the energy usage of mobile applications." In Mobile Computing Systems and Applications, 1999. Proceedings. WMCSA'99. Second IEEE Workshop on, pp. 2-10. [4] Kansal, A. and Feng, Z. 2008. "Fine-grained energy profiling for poweraware application design." ACM SIGMETRICS Performance Evaluation Review 36, no. 2 (2008): pp. 26-31. [5] Bartalos, P., Blake, M.B., and Remy, S. 2011. "Green Web Services: Models for Energy-Aware Web Services and Applications" IEEE International Workshop on Knowledge and Service Technology for Life, Environment, and Sustainability (KASTLES 2011), pp. 1-8. [6] Bartalos, P. and Blake, M.B. 2012. Green Web Services: Modeling and Estimating Power Consumption of Web Services, IEEE International Conference on Web Services (ICWS 2012), pp. 178-185. [7] Wei, Y. and Blake, M.B. 2010. Service-Oriented Computing and Cloud Computing: Challenges and Opportunities, IEEE Internet Computing, Vol. 14, No. 6, pp. 72-76. [8] Talebi, M. and Way, T. 2009. Methods, metrics and motivation for a green computer science program, SIGCSE Bull, vol. 41, no. 1, pp. 362 366. [9] Ghose, A., Hoesch-Klohe, K., Hinsche, L., and Le L. S. 2010. Green business process management: A research agenda, Australasian Journal of Information Systems, vol. 16, no. 2. [10] Murugesan, S. 2008. Harnessing Green IT: Principles and Practices, IT Professional, vol. 10, no. 1, pp. 24 33. [11] Rivoire, S., Ranganathan, P., and Kozyrakis, C. 2008. A comparison of high-level full-system power models, in Proceedings of the 2008 conference on Power aware computing and systems, 2008, pp. 3 3. [12] Li, T. and John, L. K. 2003. Run-time modeling and estimation of operating system power consumption, SIGMETRICS Perform. Eval. Rev., vol. 31, no. 1, pp. 160 171. [13] Le Sueur, E. and Heiser, G. 2010. Dynamic voltage and frequency scaling: the laws of diminishing returns. Proceedings of the 2010 international conference on Power aware computing and systems, HotPower10. pp. 1-8. [14] David, H., Fallin, C., Gorbatov, E., Hanebutte, Ulf R., and Multu, O. 2011. Memory Power Management via Dynamic Voltage/Frequency Scaling. ICAC 11 Proceedings of the 8thACM international conference on Autonomic computing, pp. 31-40. [15] Liang, W., Chen, S., Chang, Y., and Fang, J. 2008. Memory-aware dynamic voltage and frequency prediction for portable devices. In Embedded and Real-Time Computing Systems and Applications, 2008. RTCSA 08. 14th IEEE International Conference, pp. 229 236. [16] Blake, M.B. and Gomaa, H. 2009. "Agent-Oriented Compositional Approaches to Services-Based Cross-Organizational Workflow", Special Issue on Web Services and Process Management, Decision Support Systems, Vol. 40, No. 1, pp 31-50. [17] Do, T., Rawshdeh,S. and Shi, W. 2009. "ptop: A process-level power profiling tool." Proceedings of the 2nd Workshop on Power Aware Computing and Systems (HotPower 09). [18] Chen, H., Wang,s and Shi,W. 2011. "Where does the power go in a computer system: Experimental analysis and implications." In Green Computing Conference and Workshops (IGCC), 2011 International, pp. 1-6. [19] Grochowski, E. and Annavaram, M. 2006. "Energy per Instruction Trends in Intel Microprocessors " Technology@Intel Mag., pp. 1-8 597