Approximating Quality Contracts for Energy Auto-tuning Software Sebastian G¨otz, Claas Wilke, Sebastian Richly, and Uwe Aßmann Software Technology Group, Department of Computer Science Technische Universit¨at Dresden, D-01062 Dresden, Germany
[email protected], {claas.wilke, sebastian.richly, uwe.assmann}@tu-dresden.de Abstract—An emerging trend for future software systems is self-optimization, especially w.r.t. energy efficiency. Models of soft- and hardware components at runtime, expressing current and alternative system configurations, are exploited to improve service utility as well as to decrease energy consumption. In recent work we showed how quality contracts—expressing dependencies between software and hardware components— can be used for energy auto-tuning. Notably, the declared provisions and requirements of individual components depend on software containers (i.e., the servers, components are deployed on) and thus, cannot be declared completely at design time. In this paper we present a semi-automated contract creation process that combines manual created contract templates with benchmarking and mathematical approximations for nonfunctional properties depending on the components’ runtime behavior as well as their service’s input parameters. We identify individual process activities and show how the process can be applied to approximate the non-functional behavior of software components providing simple sorting functionality. Keywords-Quality Contracts, Benchmarking, Energy SelfOptimization.
I. I NTRODUCTION The development of self-adaptive software systems has been a well-discussed research topic for more than ten years. Self-optimizing software systems—a particular kind of self-adaptive systems—are of special interest for green computing, because they provide the basic mechanisms for tradeoff analysis between energy efficiency and other quality requirements. The basic idea is the realization of a control loop in the presence of goals: (1) systems collect information about themselves, (2) analyze this information, (3) decide for required actions to adapt to new requirements or to optimize themselves and (4) perform these actions. These four steps can be performed in a continuous loop resulting in multiple adaptations and optimizations during runtime. In recent work we presented the multi-quality auto-tuning (MQuAT) approach for the development of componentbased software capable of self-optimization [1]. MQuAT requires the modeling of software and hardware as components with explicitly defined non-functional properties (NFPs). The key enabler are quality contracts [2], which describing the non-functional variability of software components. Each contract characterizes the NFPs of an implementation for a specific software component. The decision making is performed by an optimizer, which determines the best
possible system configuration (selection of implementations and their mapping to servers) in terms of efficiency (i.e., best possible utility for least possible cost). It therefore negotiates the quality trade offs, divided into quality provisions and requirements, specified by the contracts. One concretization of MQuAT is Energy Auto-Tuning (EAT), where the system focuses on optimization of energyrelevant NFPs in server landscapes. Namely, it focuses on the reduction of CPU time and the amount of data read and written to hard disc drives and network devices as discussed in [3]. The approach does not consider the utilization of displays, because they are drivers of energy consumption in desktop computer settings, but not in server settings. According to [3], resource temperature and cooling power are major influences, too. Thus, if respective temperature sensors are available, these NFPs can be considered as well. Notably, if accessible energy sensors exist, they can be considered, too. The measurement of NFPs for a particular software component depends on the properties of the utilized hardware resources. For example, a purely CPU-bound implementation (i.e., an implementation which does not do any input/output operations except at its start and end) will execute faster on a CPU with higher frequency than on the same CPU with lower frequency. In consequence, contracts declaring NFPs of software components are hardware- and thus, often serverspecific. In addition, NFPs often depend on client data. For example, the time required by a sort algorithm depends on the number of elements subject to sorting, which is given (or at least selected) by the client. Further examples are the size of a video to be played or the resolution of an image to be processed. Thus, contracts are bound to input parameters or (typically) their metadata (e.g., their size). Under these conditions, to declare software component contracts expressing, we identified three phases of contract concretization: First, at development time contracts can be expressed as templates that need to abstract from the utilized server and client data. Second, at deployment time the concrete server on which components are deployed as well as its configuration are known and thus, hardware influences on NFPs can be approximated. Finally, at runtime when a client actually requests a service provided by a component, concrete NFP expected to provide the service
can be computed by instantiating the contract. In this paper we focus on the process of contract creation and concretization during these phases as a prerequisite for the development of EAT software systems. We show how a combination of benchmarking and mathematical approximation can be used to derive non-functional contracts at deployment time from benchmarks developed at design time. The resulting contracts can afterwards be instantiated at runtime to predict the hardware requirements for specific service requests and thus, can be used to optimize the system w.r.t. energy. We use a simple sort component as a running example to illustrate the approach and discuss limitations and threats to validity. The remainder of this paper is structured as follows. Sect. II gives a short overview on MQuAT with special focus on EAT to motivate the application of quality contracts for the optimization of software’s energy efficiency. We present the three phases of our contract creation process in Sect. III. Next, we evaluate the presented approach and discuss threats to validity in Sect. IV. Related work is summarized in Sect. V and in Sect. VI we conclude the paper. II. M ULTI -Q UALITY AUTO -T UNING As outlined above, the EAT approach focuses on energy savings due to software self-optimization at runtime. In EAT, software as well as hardware is modeled in a componentbased manner. Different solutions for software services can be implemented using different algorithms. For example, a component type sorting an array can be realized using heapsort or quicksort which both fulfill the same service, but require different amounts of memory and CPU time as well as provide different worst-case execution times (WCETs). Besides software variability due to different implementations, the underlying hardware can vary as well (e.g., the same service can be provided on different servers in a distributed system). Thus, in EAT, hardware is also modeled as components, whereby different devices can represent the same resource types, but provide different qualities (e.g., two CPUs having different CPU frequencies can be represented by the same CPU component type). The central idea behind EAT (and the more general MQuAT approach) is to provide software clients the expected quality of service (QoS), whereby minimizing the required hardware resources for these services, and thus reducing the required energy. In some cases, the expected QoS will always be the maximum quality that can be provided (e.g., minimum response time when sorting an array of data). However, in other cases the highest possible quality might be unnecessary (e.g., refreshing data with high frequencies although users are not able to perceive these updates with the same frequency) and thus, approaches just optimizing the possible QoS potentially waste resources and energy. Therefore, we propose a contract negotiation approach [4] that computes the most resource saving configuration that is
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
c o n t r a c t H e a p S o r t implements S o r t { / ∗ Q u a l i t y mode f o r f a s t CPUs . ∗ / mode f a s t { r e q u i r e s r e s o u r c e CPU { min f r e q u e n c y : 2 . 0 [ GHz ] ; min t i m e : 1 . 1 4 7 ∗ 1 0 ˆ ( − 6 ) ∗ s i z e o f l i s t ˆ2 −1922 [ ms ] ; } p r o v i d e s min r e s p o n s e t i m e : 2 . 1 5 2 ∗10ˆ( −6) ∗ s i z e o f l i s t ˆ2 −1917 [ ms ] ; } / ∗ Q u a l i t y mode f o r s l o w e r CPUs . ∗ / mode s l o w { r e q u i r e s r e s o u r c e CPU { min f r e q u e n c y : 0 . 8 [ GHz ] ; min t i m e : 1 . 5 5 2 ∗ 10ˆ( −6) ∗ s i z e o f l i s t ˆ2 −1821 [ ms ] ; } p r o v i d e s min r e s p o n s e t i m e : 3 . 5 5 2 ∗ 10ˆ( −6) ∗ s i z e o f l i s t ˆ2 −1901 [ ms ] ; } } Listing 1.
Example QCL Contract for a Sort Component.
able to provide a requested service and the required QoS. As the name implies, contract negotiation uses contracts that declare the NFPs provided by and required for individual software components. In our implementation of MQuAT, these contracts are expressed using the Quality Contract Language (QCL). An example for a QCL contract is shown in Listing 1. A component implementation HeapSort provides the services of a Sort component in two different quality modes: A fast mode can provide the sorting service with a response time depending on the input data’s size (size of list). In contrast, the slow mode requires a CPU that is able to process the sorting algorithm with a frequency of 2GHz and is available for a specified amount of time. Alternatively, the HeapSort component can run in a slow mode on a slower server whereby requiring less CPU frequency but longer execution time and thus, longer response time. To develop applications using EAT, it is necessary to declare similar contracts for all implementations of all component types of the system. For practical reasons it is unlikely that software developers are able to declare contracts for all their components by hand. For example, they might not know, how long a specific implementation will run on the available servers and how much resources it will require. An automated approach is required that benchmarks the developed software on the available hardware and derives concrete values for the provisions and requirements of the software’s contracts. In the following section we present an approach to declare QCL contracts semi-automatically. Afterwards, we evaluate the accuracy and discuss limitations of the approach in Sect. IV.
Phase 1: Design Time
1. Application Development
Contract Template
Phase 2: Deployment Time
4. Approximation
Phase 3: Runtime
Contract
5. Instantiation
Contract Instance
Measurement Results
User Request
Legend
Code
2. Benchmark Development
Benchmark Parameter Metadata
3. Profiling
Activity
Available Resources
Figure 1.
Information
Process of Contract Creation.
III. C ONTRACT G ENERATION In this section we discuss the process of contract creation, consisting of three major phases related to application design time, deployment time and runtime (cf. Fig. 1). The first phase is the application development at design time, consisting of the activities application development— where the component implementation (code) is created— and benchmark development: Using profiling techniques the developer investigates the non-functional behavior of the code to determine possible quality modes as explained in Sect. III-A. Using the gained knowledge, the developer creates a benchmark, which will benchmark the code on each server the code shall be deployed on during a second phase deployment time (profiling activity), as explained in Sect. III-B. The execution of the benchmark at deployment time leads to measurement results which are correlated with service parameter metadata in the form of mathematical functions mapping the metadata to the measurement results (approximation activity). Finally, the runtime phase when a client request a service, the request’s metadata is known and, thus, the approximated resource utilization functions can be evaluated (instantiation activity) as shown in Sect. III-C. The resulting information (e.g., the request-specific approximated CPU time) is used in later steps of the control loop to optimally configure the system for clients’ service requests. A. Design Time: Application and Benchmark Design During design time of self-optimizing software, application developers do not just need to design and implement, but are required to explore the non-functional behavior of their implementations. The measurement of selected NFPs, which enable to negotiate between multiple implementation variants at runtime (e.g., heapsort versus quicksort), is essential. With regard to server’s energy consumption, the focus should be on the identification of the required CPU time and the amount of data read and written to hard disk drives and network devices.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
c o n t r a c t H e a p S o r t implements S o r t { / ∗ Q u a l i t y mode f o r f a s t CPUs . ∗ / mode f a s t { r e q u i r e s r e s o u r c e CPU { min f r e q u e n c y : 1 ∗ cpu . f r e q u e n c y . max [ GHz ] ; min t i m e :< f c p u t i m e >( s i z e o f l i s t ) [ ms ] ; } p r o v i d e s min r e s p o n s e t i m e : ( s i z e o f l i s t ) [ ms ] ; } / ∗ Q u a l i t y mode f o r s l o w e r CPUs . ∗ / mode s l o w { r e q u i r e s r e s o u r c e CPU { min f r e q u e n c y : 0 . 4 ∗ cpu . f r e q u e n c y . max [ GHz ] ; min t i m e : ( s i z e o f l i s t ) [ ms ] ; } p r o v i d e s min r e s p o n s e t i m e : ( s i z e o f l i s t ) [ ms ] ; } } Listing 2.
QCL Contract Template for a Sort Component.
To gain the values of these NFPs at runtime, the developer cannot simply measure these NFPs on his own machine. This is because the NFPs depend on the utilized resources and the actual user requests. Hence, the developer needs to write a benchmark suite for his implementation, which—in the best case—covers its complete non-functional behavior (i.e., all possible behaviors). This suite is run at deployment time when the available resources are known. Notably, already at design time, developers are able to identify quality modes. These are setups in which their code requires different amounts of resources and provides different NFPs in return. For the introduced sorting example, which is a purely CPU-bound algorithm, different frequencies of the CPU lead to valuable differences in the CPU time. A developer could, thus, identify two (or more) quality modes, which he specifies in a contract template for his code as shown in Listing 2. For each mode a
Table I CPU DATA ( MEAN (cpu time), STANDARD DEVIATION (σcpu time ) AND STANDARD ERROR OF THE MEAN (SEcpu EACH size of list PROFILED 50 TIMES . size of list ∗ 10−5 cpu time [μs] σcpu time [μs] SEcpu time [%]
0.5 1388.7 749.4 7.6
1.0 9616.3 1549.4 2.3
1.5 23956.8 2508.3 1.5
2.0 43951.7 3210.4 1.0
fixture is specified, which—in the example—represents the CPU frequency. For the fast mode, 100% of the maximum available CPU frequency is specified. For the slow mode, only 40% are specified. The fixture describes values for NFPs that can vary depending on the service request’s input data at runtime. E.g., the NFP response time of the sort example is derived from the f response time time which itself depends on the size of list of the input data (c.f. Listing 2 line 9). In this context, represents a function which is approximated during profiling and will be replaced by the approximated function during the contract creation process (activity approximation). Quality modes can be seen as modes of operation in a specified system setup (e.g., fixed CPU frequency). In general, two types of setups need to be considered: (1) NFPs can be influenced by the control loop to reach a certain system configuration (e.g., setting the CPU frequency) and (2) the NFPs cannot be influenced (e.g., if the mode is defined to apply for a certain minimum amount of remaining main memory capacity). For optimization (determining the best configuration), this difference is important, because in the first case each mode can be reached and, hence, has to be considered, whereas in the second case only the currently applicable mode needs to be considered, because the other mode cannot (or is not meant to) be reached (setting CPU frequency versus main memory capacity). The rational behind quality modes is to enable executions with lower quality, which in turn lead to lower energy consumption. In the next subsection, we show how the expressions of function templates can be determined at deployment time. B. Deployment Time: Profiling and Approximation To profile the resource usage of an application, a variety of benchmarking and performance measurement tools is available. Common tools support the measurement of total execution time (e.g., response time, wall time), CPU time, network as well as disk I/O and memory utilization. Developers manually invoke these tools and interpret the results to deduce knowledge about the application’s nonfunctional behavior. However, the profiling process should be automated where possible to ease the time-consuming process of profiling, approximation and contract instantiation. Thus, at deployment time, the designed benchmarks are used to profile the resource requirements of designed software components deployed on a certain server w.r.t. to
2.5 69491.5 4088.5 0.8
3.0 100901.7 4909.4 0.7
3.5 137647.4 5674.7 0.6
time
4.0 181522.2 6639.0 0.5
)) FOR HEAPSORT EXAMPLE ,
4.5 230407.3 7343.5 0.5
5.0 284935.8 8449.4 0.4
cpu time(size of list) = 1.147 ∗ 10−6 ∗ size of list2 − 1922 Figure 2.
Approximated Function for Data from Table I.
varying input data (e.g., lists of different sizes). Afterwards, the benchmark data is used to approximate a function that allows for predicting the resource requirements depending on the service requests’ input data. For that purpose we developed a profiling infrastructure that performs the complete deployment time phase automatically. It executes the benchmark and profiles the server’s hardware, resulting in data correlating the service’s input data and its NFPs (c.f. Table I, example data collected for the heapsort example on a HP Envy 15 laptop1 ). Afterwards, the Eureqa [5] tools are used to derive a mathematical function from the collected data and can be used to replace the fixture in the contract template (cf. Fig. 2 and Listing 1). Eureqa is based on an evolutionary algorithm that continuously searches for functions, which approximate the data collected by the benchmark suite. Each function has a fitness value, which expresses the variance relative to the measured data. To ensure termination, the approximation activity uses a target fitness value to be reached as well as a timeout to terminate the approximation algorithm (the example function shown in Fig. 2 has a fitness value of 0.02 (i.e., almost exactly represents the data of Table I). In Sect. IV we further discuss the accuracy and quality of the profiled data as well as the derived function. Notably, the benchmark suite needs to be executed for each setup defined by the fixture in the quality modes of the contract to be created. In our example, the benchmark suite collects CPU and response time once for the CPU running at 100% of its maximum frequency and again at 40% of its frequency. To set the frequency of a CPU various tools exists (e.g., acpi-cpufreq for Linux). This setup is part of the benchmark suite. Depending on the resource properties, which are part of fixtures (e.g., remaining main memory), sophisticated setup code results. For the sort example the benchmark and approximation suite results in the contract shown in Listing 1. 1 CPU: Intel Core i7 720QM quad core 1.6 GHz, 8 GB RAM, SATA2 HDD, running Fedora 16 with Linux Kernel Version 3.2.2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
/ / s i z e o f l i s t = 500.000 c o n t r a c t H e a p S o r t implements S o r t { / ∗ Q u a l i t y mode f o r f a s t CPUs . ∗ / mode f a s t { r e q u i r e s r e s o u r c e CPU { min f r e q u e n c y : 2 . 0 [ GHz ] ; min t i m e : 47 [ ms ] ; } p r o v i d e s min r e s p o n s e t i m e : 104 [ ms ] ; } / ∗ Q u a l i t y mode f o r s l o w e r CPUs . ∗ / mode s l o w { r e q u i r e s r e s o u r c e CPU { min f r e q u e n c y : 0 . 8 [ GHz ] ; min t i m e : 1 4 0 . 2 [ ms ] ; } p r o v i d e s min r e s p o n s e t i m e : 244 [ ms ] ; } } Listing 3.
User Request-Specific QCL Contract.
C. Runtime: Contract Instantiation The third and last phase of quality contract creation in self-optimizing software systems is the instantiation of contracts at runtime, when a client requests functionality of the component implementation characterized by the contract. At this point in time, the functions derived during the deployment phase can be evaluated for the actual user input. In our example, the client could request to sort a list of 500.000 elements, which results in a contract instance as shown in Listing 3. These concrete values can now be used for optimization, that is to determine the best system configuration (selection of implementations and their mapping to servers) in terms of energy efficiency as we showed in [4]. IV. T HREATS TO VALIDITY In this section we show threats to the validity of our approach and discuss its limitations. For that purpose we focus on three central issues: (1) limitations, due to the resolution of measured NFPs, (2) the accuracy of functions comprised by contracts, and (3) limitations due to correlations of service input data and the profiled NFPs. A. Measurement Resolution Limitations It is important to note that NFPs on the level of an application cannot be measured without an error value. This is, because the application runs on top of an operating system (OS), which in turn runs on top of hardware. Both, the operating system and the hardware influence the NFPs of software: on hardware level the system management mode preempts even the operating system and the operating system itself is responsible to assign resources to the application process. In consequence, a minimum resolution for the measurement of NFPs exists, which depends on the actual hardware and OS. On a standard Linux, for example, the minimum resolution of timing information is determined
by the frequency of the process scheduler. By default the scheduler runs every 10ms. In consequence, it is impractical to measure the time required by a method call, which runs in less than 10ms. Although it is possible to use timing information provided by the real-time clock, which is implemented in hardware and usually provides a resolution in nanoseconds. However, the scheduler will not delegate the control to another process until the 10ms time slice passed by. More sophisticated schedulers, especially those of real-time operating systems, allow for finer grained time measurements. Notably, the same minimum resolution can be shown for other NFPs like the amount of data read or written. For data transfer (to a disk or network device) the device driver and file system determines the minimum size of a data block to be read or written. For the measured sort example depicted in Sect. III-B, we measured a standard error of 7.6% for lists of 50.000 elements which questions the usability of the approximated resource usage function for lists of this size. Besides, statistical outliers are up to 80% higher and lower than the mean. However, for lists consisting of 200.000 elements the error decreases to 1% and below for even bigger lists whereby outliers decrease to ±12% and to ±5% for 500.000 elements. This matches the assumption that our approach is limited due to minimum measurement resolutions of the hardware infrastructure. Another reason is that during short execution times unpredictable events like garbage collection or the hardware’s system management mode can influence the results more intensely. Only methods, whose NFPs are higher than the minimum resolution can be considered. If the NFPs have lower values, the characterized implementation cannot be compared with other implementations. For the sort example, the parameter size plays an important role. For lists of less than approximately 150.000 elements, the algorithm runs in less than 10ms and hence, cannot be practically characterized in terms of time. Prolonging the runtime by multiple executions to compute average values for the NFPs does not solve this problem, because the error of such average values are multiples of 100%. B. Accuracy of Derived Functions As every measurement of NFPs introduces an error, the accuracy of the derived functions can never reach 100%. Nevertheless, the error (and deviation) of an approximated function can be estimated. This estimation depends on the size of the NFP under investigation. The minimum error is determined by the minimum resolution of the NFP as pointed out in the last subsection. In principle, it is not possible to measure a maximum error in general. For example, the time required for a method to execute can theoretically be delayed forever. Practically, the delay is bound to some external entity, which imposes the delay (waiting for user input, waiting for crashed servers to reboot). Nevertheless, for implementations which are not affected by such external
influences, it is possible to get a practical error estimation by computing the average error of multiple benchmark executions. Knowing the average error of a particular NFP directly leads to the average error of a derived function on this NFP. For our example function shown in Fig. 2, the average error equals the error of the NFP cpu time. C. Parameter–NFP Correlation A third limitation of our approach lies in the fact, that services’ NFPs are not always related to their input parameters and the parameters’ metadata. According to Seo et al., three different types of service interfaces can be identified: 1) Services always behaving the same independent of their input data, 2) Services behaving proportionally to the given parameters (and their metadata), 3) Services behaving unpredictable (e.g., database queries or randomized data). Whereas the NFP approximation for the first two categories is supported, the third kind of services cannot be supported, as approximated functions cannot be based on the input data and, thus, only coarse-grained statistical approximations are possible. V. R ELATED W ORK The presented process of contract creation in the context of EAT/MQuAT is not the first approach utilizing quality contracts for self-optimizing software systems. However, to the best of our knowledge, no other approach exists that addresses the issue of incomplete information at design and deployment time. Foundations for self-optimizing software systems based on quality contracts have been achieved by Aagedal [6]. He defined the contract language CQML that enables the expression of QoS dependencies between individual software components. Aagedal did not focus on resource or energy optimization. In consequence, CQML does not include the description of software-hardware dependencies. The COMQUAD research project extended CQML with hardware dependencies, resulting in CQML+ [7], which mainly inspired our design of QCL. Although CQML+ allows for the specification of resource usage implications, hardware devices cannot be modeled like in EAT/MQuAT. This denies to negotiate the resource budgets of available devices. Moreover, the COMQUAD approach does not include profiling nor deriving of software-hardware dependencies. The MADAM/MUSIC research project resulted in a component model for mobile self-adaptive applications [8]. It supports the modeling of NFPs and their relations by means of model annotations (a UML profile). The approach does not encapsulate provided and required NFPs in contracts and, hence, cannot capture the knowledge of the developer about the non-functional code behavior, like quality modes and parameter metadata influencing the resource usage to
name but a few. In the DIVA research project [9], components do not declare their provided and required NFPs. Instead a sophisticated quality grading model is provided, which allows for the specification of quality dimensions (e.g., energy, time, accuracy, ...) and an assessment of code in terms of a finite set of grades. It furthermore allows the specification of priorities between quality dimensions. Although software-hardware dependencies can be expressed in a coarse-grain level using the quality grades, DIVA abstracts from concrete NFP values to symbolic categories (e.g., the grades low and high for the CPU usage dimension). An approach to estimate the hardware utilization of specific software components is not part of the DIVA approach. A further component-based approach to self-adaptive systems is the ConFract approach [10], particularly focusing on self-healing systems. Functional contracts are used to specify how a valid system is characterized and to initiate self-healing in case of contract violations. In ConFract, the developer is able to explicitly specify resource usage profilers as part of the system. In consequence, the functional contracts, which use data generated by these profilers, can be used as non-functional contracts, so dependencies between NFPs can be expressed. In [11], Le Duc et al. present an adaptive monitoring framework called ADAMO to be used in ConFract for the resource usage profilers. ADAMO is a self-adaptive profiling infrastructure. Depending on the quality of information required by the users, the profiling infrastructure adjusts itself to collect exactly what is needed. Notably, ConFract in combination with ADAMO does not consider the second phase of our contract creation process, where functions mapping user input to resource usage are automatically derived. Instead, the developer has to specify this information on his own in the form of a monitoring query. The JouleSort benchmark developed by Rivoire [12] allows for benchmarking different PCs’, servers’ and laptops’ hardware w.r.t. energy consumption. It extends classical sort benchmarks, but shifts their fitness function from performance and throughput to energy consumption. Different hardware devices are profiled using a power meter when running on external power. Besides JouleSort, Rivoire developed the tool Mantis [12] that enables the derivation of mathematical functions predicting the energy consumption of the profiled devices based on workload characteristics such as the utilization of CPU, memory and hard disk drive. Our approach can be considered similar as it tries to derive mathematical functions for the software’s resource requirements by running benchmarks on the profiled devices. However, Mantis produces formulas based on utilization data such as CPU and I/O usage and, thus, requires a usage analysis of these values for its energy prediction. Our approach in contrast derives formulas that express resource utilization depending on input data.
Lafond et al. [13] implemented a framework for measuring the average energy consumption of individual Java bytecode instructions executed on a specific Java virtual machine (JVM). They profiled the energy consumption of a large subset of all Java bytecode instructions and evaluated their measurements using several benchmarks. Another but similar framework was implemented by Seo et al. [14]. Both approaches allow the prediction of energy consumption for a sequence of program instructions (i.e., a program). However, the execution of a set of instructions does not necessarily consume the sum of each instruction’s energy consumption, due to the performance/energy-saving modes of hardware, which can change over time. Thus, to reduce the error of the energy consumption prediction, it is necessary to measure complete methods and applications, like we propose in this paper for resource consumption in general.
ACKNOWLEDGEMENTS This research has been funded by the Collaborative Research Center 912 (HAEC), funded by the DFG and within the project ZESSY #080951806, funded by the European Social Fund (ESF) and Federal State of Saxony.
VI. C ONCLUSION AND F UTURE W ORK
[4] S. G¨otz, C. Wilke, S. Cech, and U. Aßmann, “Runtime variability management for energy-efficient software by contract negotiation,” in Proceedings of the MRT’11 workshop, 2011.
In this paper we presented an approach to specify quality contracts, characterizing the non-functional behavior of component implementations, and a process capable of handling the server and user dependencies of NFPs. We gave an overview on our approach to develop self-optimizing software systems in Sect. II and identified the process of contract creation as a key issue. The process of contract creation, divided into three phases, has been presented in Sect. III. Finally, we discussed limitations of our approach in Sect. IV and demarcated it from related work in Sect. V. We particularly focused on energy-relevant NFPs of software components in the context of EAT, a focused version of our general MQuAT approach. The three phases of contract creation comprise design time, deployment time and runtime. At design time, the developer is in charge of writing a benchmark suite for his implementation and to specify a contract template, which contains information about possible quality modes. Each of these modes is specified in terms of a fixture, which denotes certain settings of resource properties (e.g., CPU frequency). In addition, the provided and required NFPs are abstracted by function templates. The developer only specifies the relevant parameter metadata, like the length of a music file to be played. At deployment time, the benchmark suite is executed and the serverspecific expressions for the function templates are computed. Finally, at runtime, the user input is used to compute the parameter metadata, which allows evaluating the functions. The resulting NFP values are than used to optimize the software system. In future work we will investigate how to include values collected by future, high-resolution energy sensors of hardware and by external measurement equipment in the presented process to enable the expression of energy consumption provisions and requirements in contracts. In addition, we plan a complex case study in the domain of image analysis for Alzheimer’s disease research.
R EFERENCES [1] S. G¨otz, C. Wilke, S. Cech, and U. Aßmann, Sustainable ICTs and Management Systems for Green Computing. IGI Global, 2012, ch. Architecture and Mechanisms for Energy Auto-Tuning. [2] A. Beugnard, J.-M. J´ez´equel, and N. Plouzeau, “Contract aware components, 10 years after,” in Proceedings of WCSI’10 Workshop, 2010, pp. 1–11. [3] R. Bianchini and R. Rajamony, “Power and energy management for server systems,” IEEE Computer, vol. 37, no. 11, pp. 68 – 76, Nov. 2004.
[5] M. Schmidt and H. Lipson, “Distilling free-form natural laws from experimental data,” Science, vol. 324, no. 5923, pp. 81– 85, 2009. [6] J. O. Aagedal, “Quality of service support in development of distributed systems,” Ph.D. dissertation, University of Oslo, Norway, 2001. [7] S. R¨ottger and S. Zschaler, “CQML+: Enhancements to CQML,” in Proceedings of the 1st International Workshop on Quality of Service in Component-Based Software Engineer´ ing. Toulouse, France: C´epadu`es-Editions, 2003, pp. 43–56. [8] K. Geihs, M. U. Khan, R. Reichle, A. Solberg, S. Hallsteinsen, and S. Merral, “Modeling of component-based adaptive distributed applications,” in Proceedings of the SAC’06. New York, NY: ACM, 2006, pp. 718–722. [9] F. Fleurey and A. Solberg, “A domain specific modeling language supporting specification, simulation and execution of dynamic adaptive systems,” in Proceedings of the MODELS’09. Berlin, Heidelberg: Springer, 2009, pp. 606–621. [10] H. Chang and P. Collet, “Compositional patterns of nonfunctional properties for contract negotiation,” JSW, vol. 2, no. 2, pp. 52–63, 2007. [11] B. L. Duc, P. Collet, J. Malenfant, and N. Rivierre, “A QoIaware Framework for Adaptive Monitoring,” in Proceedings of ADAPTIVE 2010. IEEE, 2010, pp. 133–141. [12] S. M. Rivoire, “Models and Metrics for Energy-Efficient Computer Systems,” Ph.D. thesis, Stanford University, 2008. [13] S. Lafond and J. Lilius, “An Energy Consumption Model for an Embedded Java Virtual Machine,” in Proceedings of ARCS’06. Springer Berlin / Heidelberg, 2006, pp. 311–325. [14] C. Seo, S. Malek, and N. Medvidovic, “An energy consumption framework for distributed java-based systems,” in Proceedings of the ASE’07. ACM Press, 2007.
