Monitoring energy hotspots in software

we note that power consumption is not always linearly dependent to the percentage of CPU utilization. This is due to dynamic voltage and frequency scaling (DVFS) and also to the fact that power depends on the voltage (and subsequently the frequency) of the processor. For example, a process at 100 % CPU utilization will not necessarily consume more power than a process running at 50 % CPU utilization but with a higher voltage. Therefore, a simple CPU utilization profiler is not enough in order to monitor power consumption.

Our results show network consumption around 0.017 W compared to CPU consumption of Iperf process around 0.9 W. These numbers show that, although CPU power is quite low (average around 0.9 W) and the network card uses all its capacity, the consumed network power is largely negligible

These results outline the importance of using percentages when comparing energy consuming of software code. This is mainly due to the different hardware that machines use, thus consuming different amount of energy while still keeping similar energy trends and distribution in software.

The goal of our approach is to detect where the energy is being spend in software, or energy hotspots. This detection allows developers and other users to understand where and how the energy is consumed, and also to detect abnormal functioning in applications (e.g., energy bugs).

We stress Jetty’s asynchronous REST web application example (async-rest) using ApacheBench. The latter uses 25 concurrent users with 100,000 requests. We run the experiment 5 times, for around 205 s in total execution time (the first run at 54 s, then the others run at 37 s in average due mainly to the Java JVM’s JIT functionality).

The goal of our approach is to observe trends in energy consumption and profile applications to detect energy hotspots. Therefore, we argue that using percentages when comparing energy consumption of methods and classes is more useful and representative than raw values. Our approach is thus useful in profiling applications in order to find the origin of energy leaks. Developers can then provide hotfixes for the application in order to reduce its energy footprint.

Our results show a low overhead for sampling (at around 3 %), in comparison to the high overhead of instrumentation (at around 130 %). This overhead cripples any real world uses of instrumentation for energy measurements.

In Seo et al. (2007), the authors propose formulae to compute the energy cost of a software component as the sum of its computational and communication energy costs. For a Java application running in a virtual machine, the authors take into account the cost of the virtual machine and eventually the cost of the called OS routines.

In Kansal and Zhao (2008), the authors take into account the cost of the wait and idle states of the application (e.g., an application consumes energy when waiting for a message on the network). We also take these states into account by only using the actual time spent running on a resource (i.e., CPU, network card).

Several open-source or commercial Java profiling tools already propose some statistics of Java applications. Tools, such as VisualVM, Java Interactive Profiler (JIP), or the Oktech Profiler, offer coarse-grained information on the application and fine-grained resource utilization statistics. However, they fail in providing power consumption information of the application at the granularity of threads or methods. For example, the profiler of VisualVM only provides self wall time (e.g., time spend between the entry and exit of the method) for its instrumented methods.