Introduction

Computing is becoming a pervasive and ubiquitous part of everyday life. This has led to important design considerations from the software, the need to provide a seamless and portable software platform that facilitates easy inter-operability, and hardware, the need to incorporate energy and form factor conscious designs and to reduce time-to-market and cost, angles. This paper brings these two design considerations together by examining the energy consumption of JVM implementations that form the cornerstone of Java [1], which is one of the software platforms for the seamless integration of diverse ubiquitous/embedded devices. In particular, this paper focuses on the energy consumed by the memory system when executing the SPEC JVM98 benchmarks [27].

Java provides portability across systems by specifying only the format and semantics of the bytecodes, without placing any restrictions on how they are executed. Consequently, the choice of the JVM implementation style depends on the performance, availability of hardware resources, as well as energy criteria. Previous studies have mainly looked at performance and hardware resource issues between JVM implementation styles. This is one of the first studies to examine JVM implementation styles from the energy viewpoint. Energy, measured in Joules, is the power consumed over time and is an important metric to optimize for prolonging battery life. The importance of optimizing for this metric has been further accentuated by the slow improvements in the energy capacity of batteries.

The focus of this paper is in studying the energy consumption behavior of the Java codes from both software and hardware perspectives. While energy consumption is an important issue in mobile systems of varying degree of resource constraints, the experimental setup and evaluation benchmarks used in this work are representative of high-end mobile devices such as laptops. The JVM used in our experiments is the Sun Labs Virtual Machine for Research, formerly known as ExactVM (EVM) [31]. While current low-end mobile devices use small footprint JVMs that use simple interpretation, more sophisticated JVMs such as the one used in this work are attractive, due to their performance, for high-end mobile devices such as laptops and emerging low-end mobile devices such as palmtops with large memory modules.

We utilize the SPEC JVM98 benchmarks in this work and, specifically, focus on characterizing the memory system energy consumption for the following reasons:

• It has been observed [37,4] that the memory system can consume a large fraction of the overall system energy, making this a ripe candidate for software and hardware optimizations.
• Among the different instructions executed by the SPARC architecture while executing the SPEC JVM98 benchmarks, the load/store instructions are the primary instructions that access the memory for their operands. On the average, we find the energy consumed by load/store instructions accounts for 58.7% and 52.2% of the total energy in the interpreted and JIT-compiled modes, respectively, when executing the SPEC JVM98 benchmarks (see left side of Figure ). The energy consumed by load/store instructions is significant considering that on an average, these instructions are observed to constitute only 22.7% and 19.4% of the total instructions for the interpreted and JIT modes, respectively (see right side of Figure ).

• Finally, Java executions are expected to stress the memory system more than traditional programs [17,3,9]. Bytecodes are treated as data, and need to be fetched from memory for interpretation or JIT-compilation and installed. Further, JVM features such as garbage collection make Java executions much more memory-intensive than normal programs.

  

Figure: Energy consumption distribution between load/store and other instructions (left). Distribution of dynamic instructions categorized as load/store and other instructions when executing on a SPARC architecture (right). The energy consumption for memory references are assumed to hit in the cache and energy consumption numbers for each group of instructions are applied from [34].

We examine the energy consumption of the memory system when executing Java programs, with different JVM implementation styles, to understand the hardware and software bottlenecks. From the hardware viewpoint, such information can be used to suggest cache organizations and strategies for optimizing energy-delay criteria. Identifying energy bottlenecks for different software components of the execution, such as class loading, garbage collection or dynamic compilation, can lead to the design of better algorithms and mechanisms to reduce the energy demands. For instance, if garbage collection turns out to be energy hungry, one could either opt to invoke the collector less frequently or design more energy-conscious garbage collection algorithms. The information can also be used to decide when to interpret and when to compile, rather than base this decision purely on performance considerations.

To our knowledge, there has been only one prior study that has attempted to profile the energy consumption of Java programs [10]. However, their use of an actual pocket-computer to measure the current for calculating energy has limited their extent of profiling. It does not provide adequate information as to what hardware components are consuming the energy during the different phases of execution. On the other hand, the use of a detailed simulator helps us profile the energy consumption from both the hardware and software angles to isolate the fraction consumed by the memory system. Using the SPEC JVM98 benchmarks on off-the-shelf JVM implementations in the interpreted and JIT-compiled modes, this paper sets out to answer the following questions:

• How much energy is consumed by the memory system in the execution of Java programs? What fraction is consumed by the cache and what fraction by the main memory? What is the energy breakdown between instruction and data references?
• How do different cache configurations affect the energy consumption? In particular, what is the effect of the cache size and associativity? While cache configurations that traditionally favor locality would reduce the references to main memory and reduce memory energy consumption, those configurations would also increase the energy cost per access of the cache. Studying these trade-offs would help decide on a good operating point.
• How do these results differ between the two JVM implementation styles -- interpretation and JIT compilation? How much energy is consumed by different components of the JVM such as class loader, garbage collector? How do the cache parameters affect these components? What is the impact of application parameters, problem size in particular, on the energy consumption profile? For instance, a larger problem can result in the garbage collector being invoked more often.