Background. The Java Virtual Machine (JVM) platforms have known multiple evolutions along the last decades to enhance both the performance they exhibit and the features they offer. With regards to energy consumption, few studies have investigated the energy consumption of code and data structures. Yet, we keep missing an evaluation of the energy efficiency of existing JVM platforms and an identification of the configurations that minimize the energy consumption of software hosted on the JVM.

The Java language is rich of native and third-party I/O APIs that most Java applications and software use. Such operations can even be considered core to most software as they allow the interaction with the user and its data in a nonvolatile way. Yet, the I/O captivate a lot of attention due to their importance, but also due to the cost that these relatively slow operations add to read and write precious data, most commonly from/to disks. In this context, the impact of these I/O operations on energy consumption didn't get as much attention. Of course, I/O operations are responsible for energy consumption at the level of the storage medium (HDD or SSD) but they also induce non-negligible costs -both performance and energy-wise- at the CPU level. However, only few works take into account the impact of I/O on the energy consumption, especially at the CPU-level. Hence, this paper elaborates a detailed study with two main objectives. First we aim at assessing the energy consumption of several well-known I/O libraries methods, and investigate if different read/write methods can exhibit different energy consumption. Concretely, we assess -using micro-benchmarks-the energy consumption of 27 I/O methods for several file sizes and establish the truth about the most and least energy efficient methods. The second objective is to validate the results of the first experiments on real Java projects by substituting their default I/O methods and measuring the before/after energy consumption. Our results showed that i) different I/O methods consume very different amounts of energy, such as NIO Channels that are 20% more efficient than other methods for read purposes ii) substituting the I/O method in a software by a more efficient one can save an important amount of energy, 15% of energy saving has been registered for K-nucleotide and 3% for Zip4j. We also showed that choosing the right I/O method can save more than 30% of energy consumption when using the Javax.crypto API. Our work offers direct conclusions and guidelines on which I/O methods to use in which situation (read all data, read specific data, write data, etc.) for a better energy efficiency. It also opens doors for other works to better optimize the energy consumption of the I/O APIs and methods.

Background. As software took control over hardware in many domains, the question of the energy footprint induced by the software is becoming critical for our society, as the resources powering the underlying infrastructure are finite. Yet, beyond this growing interest, energy consumption remains a difficult concept to master for a developer.

The past decade witnessed the inclusion of power measurements to evaluate the energy efficiency of software systems, thus making energy a prime indicator along with performance. Nevertheless, measuring the energy consumption of a software system remains a tedious task for practitioners. In particular, the energy measurement process may be subject to a lot of variations that hinder the relevance of potential comparisons. While the state of the art mostly acknowledged the impact of hardware factors (chip printing process, CPU temperature), this paper investigates the impact of controllable factors on these variations. More specifically, we conduct an empirical study of multiple controllable parameters that one can easily tune to tame the energy consumption variations when benchmarking software systems. To better understand the causes of such variations, we ran more than a 1,000 experiments on more than 100 nodes with different workloads and configurations. The main factors we studied encompass: experimental protocol, CPU features (C-states, Turbo~Boost, core pinning) and generations, as well as the operating system. Our experiments showed that, for some workloads, it is possible to tighten the energy variation by up to 30x. Finally, we summarize our results as guidelines to tame energy consumption variations. We argue that the guidelines we deliver are the minimal requirements to be considered prior to any energy efficiency evaluation.