A Programming Model for Sustainable Software
Haitao Steve Zhu Chaoren Lin Yu David Liu †SUNY Binghamton, Binghamton, NY 13902, USA, Email: {hzhu1,clin18,davidL}@binghamton.edu
Abstract—This paper presents a novel energy-aware and temperature-aware programming model with first-class support for sustainability. A program written in the new language, named Eco, may adaptively adjusts its own behaviors to stay on a given (energy or temperature) budget, avoiding both deficit that would lead to battery drain or CPU overheating, and surplus that could have been used to improve the quality of results. Sustainability management in Eco is captured as a form of supply and demand matching, and the language runtime consistently maintains the equilibrium between supply and demand. Among Fig. 1. A Sustainable Program Runtime the efforts of energy-adaptive and temperature-adaptive systems, Eco is distinctive in its role in bridging the programmer and the underlying system, and in particular, bringing both programmer while at the same time producing as high-quality results as knowledge and application-specific traits into energy optimiza- possible (no surplus). In the context where “budget” refers to tion. Through a number of intuitive programming abstractions, the allowance of temperature increase — e.g., 10◦C — sustain- Eco reduces challenging issues in this domain — such as workload characterization and decision making in adaptation — ability entails temperature awareness: avoiding overheating to simple programming tasks, ultimately offering fine-grained, while producing the best results. In essence, sustainability programmable, and declarative sustainability to energy-efficient captures a recurring theme in energy and thermal management: computing. Eco is an minimal extension to Java, and has balancing the trade-off between energy/thermal budget and the been implemented as an open-source compiler. We validate the quality of computational results. usefulness of Eco by upgrading real-world Java applications with energy awareness and temperature awareness. A. Eco for Sustainable Programming Our concrete proposal is Eco, a novel and simple program- I.INTRODUCTION ming model to help developers construct sustainable software Two trajectories appear to shape up the evolution of modern by design. As we look forward, we believe programmers computing platforms: they become increasingly “nimble,” or have a unique role in application-level energy and thermal increasingly “mighty.” “Nimble” computers—such as RFIDs, management, and the future of software on “nimble” and wearable electronics, smartphones, tablets, and laptops— “mighty” computing platforms belongs to applications that often operate on battery with a limited budget. “Mighty” neither “squander” nor “skimp” on resources. computers—represented by data centers, cloud servers, and The key insight of the Eco design is that sustainability many-core clusters—not only consume a large amount of can be achieved through the negotiation between supply and energy, but also face grave reliability concerns due to excessive demand, ultimately maintaining the equilibrium of the two in heat dissipation, with cooling taking up to 35% of their op- a fashion similar to market economics. Syntactically, Eco is a erational costs [3]. Effective energy and thermal management minimal extension to Java, with two important programming is a critical goal demanding solutions from all layers of the abstractions: compute stack. In recent years, there is a growing interest in • Demand/Supply Characterization: an Eco programmer addressing these challenges from the perspective of application may associate a fine-grained program component of inter- software (e.g., [16], [5], [21], [35], [25], [17], [33], [34], [29], est (the “demand”) with a budget (the “supply”), through [32], [20], [39], [4], [36], [10], where energy and thermal a new construct called sustainable blocks efficiency is pursued and achieved throughout the software • Adaptability Support: an Eco programmer may define lifecycle. alternative application behaviors which may achieve the In this paper, we focus on an essential design goal in same application-specific goal but with different quality energy and thermal management: sustainability. A sustainable levels, through a principled and fine-grained construct program is able to “stay on budget,” neither yielding deficit called first-class mode cases nor surplus. In the context where “budget” refers to available Throughout the execution of the code enclosed in the battery — e..g., 20% battery of a smartphone — sustainability sustainable block, the Eco program runtime continuously entails energy awareness: the sustainable program makes the monitors the change in demand and supply. As demonstrated in best effort to not exceed 20% of battery usage (no deficit), Figure 1, the sustainable execution should have the remaining
*The first and second authors have recently joined Google Inc. after completing the demand (the solid line) closely matches the remaining supply work at SUNY Binghamton. (the dotted line). If demand far exceeds supply at a snapshot of the execution, the program adapts to program behaviors that 1 mode { l o <: mid }; may produce results in lower quality. If supply far exceeds 2 mode { mid <: h i }; demand, adaptation in the opposite fashion happens. 3 4 c l a s s R a y t r a c e r { In a nutshell, the design scope of Eco subsumes pro- 5 mcase
Fig. 4. Syntax Desugaring for Battery/Temperature-Aware Sustainable Programming (Let b and t variables of BatteryManager and TempManager types respectively. The BatteryManager class encapsulates the program logic for interacting with battery hardware, with one method getB to query the current battery level. The TempManager class encapsulates the program logic for interacting with temperature sensors , with one method getT to query the current temperature)
III.THE ECO DESIGN:SYNTAX AND RUNTIME SUPPORT • Q3: When to calibrate? A. Syntax Overview • Q4: When to select mode cases? Just like Java, an Eco program consists of a sequence We answer Q1 in Section III-C3 and Q2 in Section III-D. of classes, with one containing the entry method main. In To decouple Q3 from Q1, and Q4 from Q2 for presen- addition, an Eco program allows for top-level mode decla- tation purposes, we introduce two convenience expressions rations in the form of mode m <: m. We require the <: to make calibration point and mode case selection point relation defined through these declarations forms a total order. explicit, calib e, and select e. The first expression says that We further call the least element and greatest element in the calibration should be triggered after the evaluation of e, and total order the least mode and greatest mode respectively. the second expression says that the mode case represented by Implicitly parameterized by these top-level mode declarations, e should be selected. In other words, when we answer Q1 unary operators ↑ and ↓ are standard successive and precedent and Q2, we circumvent the “when” questions by assuming operators over total order. Furthermore, we define ↑ m as m if they are explicitly “marked” in the program. In Section IV, m is the greatest mode and ↓ m as m if m is the least mode. we will introduce several program transformations to answer The core expressions of Eco are defined as follows: Q3 and Q4, i.e., automatically inserting calib e and select e e ::= uniform{e} expression expressions to the Eco source program. τ | {m1 : e1; ... mn; en} | sustainable {e}(c) C. Syntactical and Runtime Support for Sustainability | select e 1) Syntax and Encodings: The general form of a sustain- | calib e able block in Eco is as follows: | Java expressions sustainable { c ::= he; e; e; ei characterizer ... // code in the sustainable block τ ::= num | X | mcasehτi type } supply ( e1 ) −> ( e2 ) For simplicity, we treat statements as expressions. Expres- demand ( e3 ) −> ( e4 ) sion uniform{e} defines a uniform block whose body is e. We where e1, e3, e4 are the expressions for representing the supply explain the rest of the syntax shortly. A type in Eco may take sum, demand sum, demand gauge we informally introduced in three forms: 1) a primitive type (e.g., integer, float), which is Sec. II, respectively. The additional expression e2 is called the abstractly represented as num for simplicity here; 2) an object supply gauge, an expression to indicate the remaining supply. type X, where X is the name of a class; 3) a type for the mode In this presentation, we also abbreviate the sustainable block case value mcasehτi, which says that the mode case has case above as sustainable {... }(he1; e2; e3; e4i), and further call members whose types are τ. he1; e2; e3; e4i the characterizer of the sustainable block. Indeed, the sustainable blocks with bsupply and tsupply B. Runtime Behavior Overview keywords introduced earlier are syntactic sugars, which can The unique runtime features of Eco center around the be encoded as in Fig. 4. As we shall see in Sec. V, Eco pro- execution of a sustainable block. There, the (sum and re- grammers can account for flexible forms of supply variability maining) supply and the (sum and remaining) demand are through supply gauge programming. monitored through checkpoints, each of which we call a step 2) Sustainable Stack: A Eco program runtime maintains a of supply/demand calibration, or calibration for short. This key data structure called a sustainability stack (represented by leads to four interconnected questions at the center of Eco S), or S-stack for short. The S-stack maintains the contexts of design: sustainable/uniform blocks: at a runtime state, each entry of • Q1: How to calibrate? this stack intuitively says that the current encountered program • Q2: How should the program adapt based on calibration point is dynamically scoped in the sustainable/uniform block (through mode case selection)? represented by the entry, with the top entry representing the most recently encountered scope. There are two important management applies to all blocks, with the most imme- features to highlight from this design: diate (inner) block first.
• Eco supports sustainability management across lexical For each instance of supply/demand matching, the supply scopes. sum expression, the supply gauge expression, the demand sum • Eco supports nested sustainable blocks, and nesting be- expression, and the demand gauge expression will in turn be tween sustainable blocks and uniform blocks. evaluated to a numerical value. Let us denote them as n1, n0 , n , n0 respectively. The matching between supply and The first support is a necessity for object-oriented lan- 1 2 2 demand is captured by the following predicate, where is a guages: object references can escape lexical scope, and as a small positive numeric constant close to 0: result, the program point of calibration may not be lexically 0 0 0 0 def n1 n2 enclosed in the sustainable/uniform blocks. In the technical MATCH(hn1; n ; n2; n i) = | − | ≤ 1 2 n1 n2 0 0 report [41], we provide a detailed example to illustrate this 0 0 def n1 n2 SURPLUS(hn1; n ; n2; n i) = − > 1 2 n1 n2 technicality. The S-stack design flexibly enables sustainability 0 0 0 0 def n2 n1 DEFICIT(hn1; n ; n2; n i) = − > management for all program points reachable from a sustain- 1 2 n2 n1 able/uniform block. Eco language implementation selects = 0.1 by default: The support of nested blocks is important for two reasons. the program is considered “sustainable” if the remaining pro- First, this facilitates modular programming, e.g., in a scenario portions of supply and demand are within ±10% difference. where the designer of a library API declares a sustainable block within the API method, and at the same time the client D. First-Class Mode Cases τ program using the API may declares its own (nesting) sus- Expression {m1 : e1; ... mn; en} represents a mode case, tainable block. More importantly, nesting support also enables where each element mk : ek (for 1 ≤ k ≤ n) in the sequence flexible sustainable programming where battery awareness and is called a case member. At run time, the expression associated temperature awareness is required at the same time. with each case member is evaluated at mode case definition Structurally, each S-stack entry can take one of the two time. As a result, each case member of a mode case holds a forms (1) a two-element tuple in the form of (e : m), where e value at runtime. is the characterizer expression of the sustainable block, and m First-class mode cases at run time are selected based on the is the mode of the current sustainable block execution, called operational mode. For now, to circumvent Q4, let us assume all the operational mode. (2) a constant element ⊥, indicating the mode case selection points are explicitly identified, through the entry representing a uniform block. select expression. The expression select e at run time evaluates When the program bootstraps, we place an initial entry to to vi following this definition: the S-stack, whose operational mode is the greatest mode in def the mode specification (a total order). This default treatment is {m1 : v1,..., mn : vn}/m = vi aligned with our intuition that an expression not reached from where e evaluates to {m1 : v1,..., mn : vn}, m is the oper- any programmer-declared sustainable block should not subject ational mode, and mi is the least mode among {m1,..., mn} to sustainability management, so the mode that represents that is equal to or greater than m according to the total order the highest quality of service is used. Upon the entry of a defined by the program. programmer-declared sustainable block, an entry (e : m) is Recall that the program bootstraps with the greatest mode. pushed to the stack, where e is the characterizer, and m is This implies when a select expression appears outside of any initially the same as the “current” operational mode before sustainable block, the greatest mode is used. This aligns with the block is entered, where the notion of “current” is defined our intuition that code not subject to sustainability manage- by the following function: ment should not be approximated.
def 0 MNOW(S) = m if S = S , (e : m) IV. THE ECO DESIGN:COMPILER SUPPORT def 0 0 MNOW(S) = MNOW(S ) if S = S , ⊥ In this section, we describe compiler support, primarily answering Q3 and Q4. This design is useful in the presence of nested sustainable blocks, where the inner block starts operating at a mode A. Automated Calibration Insertion sustainable for the outer block. We now define a compiler transformation to automatically 3) Sustainability Management as Supply/Demand Match- identify and insert calib expressions. Several design choices ing: Upon the evaluation of the calib expression, there are are possible: (1) check periodically; (2) check whenever the two possibilities: supply gauge changes; (3) check whenever the demand gauge • If any entry in the S-stack is ⊥, the calibration is a no-op. changes. Route (1) is ad hoc, especially when selecting a fixed • Otherwise, supply/demand matching will be performed “period” that fits all programs. For (2), the supply gauge in for all S-stack entries, with the top item being performed energy-aware programming is often associated with system- first. The detailed matching process will be explained level variables (such as remaining battery) whose updates are next. The definition supports nesting, where sustainability often performed outside the program runtime and out of the 0 control of programmers. This may lead to platform-dependent • τ << τ 0 00 00 behaviors: the same program may calibrate at different rates • τ << τ does not hold, and τ = mcasehτ i, and (τ % on two computers with different battery drivers. τ 0)#(e % e0). Eco follows route (3). Demand gauge is typically an ex- where the << relation is reflexive and transitive, with two pression formed with program variables, such as loop index additional rules. τ << τ 0 iff (i) τ is a subclass of τ 0; (ii) in the example in Figure 2. The state change of these variables 0 0 0 τ = mcasehτ0i and τ = mcasehτ0i and τ0 << τ0. is visible and predictable to the programmer. For application- Some examples should be sufficient to illustrate the ideas level energy management strategies—a family that Eco be- here: longs to—we believe the programmer should have control on program behaviors related to energy awareness. (mcasehnumi % num)#(e % select e) We now define the transformation process. The transforma- (mcasehmcasehnumii % num)#(e % select (select e)) tion is isomorphic except that expression e is transformed to (mcasehXi % Y)#(e % select e) where X is a subclass of Y calib e iff ¬P0(e) ∧ (P1(e) ∨ P2(e)), where: Finally, the transformation is isomorphic, except that: P0(e): e can only be reached from uniform blocks • R1: For every expression where (sub-)expression e flows P1(e): e is assignment, and the left-hand side variable to (sub-)expression e0, where the type of e and e0 are appears in the demand gauge of lexically enclosing τ and τ 0 respectively, we transform the aforementioned sustainable blocks expression to one the same as before, except that e is P2(e): e is a field write expression, and said field is read in replaced with e00, and (τ % τ 0)#(e % e00). Here, the the demand gauge of any sustainable block that may “flows-to” relation is the standard notion in data flow reach e analysis. The implementation of the three predicates has little novelty. • R2: For every expression where the (sub-)expression e P1 is a trivial local analysis. Our Eco implemented P0 and appears in a program point that serves as an object P2 through a standard context-sensitive reachability analysis. target (such as the receiver of the method inovcation, Furthermore, observe that when e is reachable from both or field read or write), we transform the aforementioned uniform blocks and non-uniform blocks, calib will be inserted. expression to one the same as before, except that e This is sound because its evaluation will become a no-op when is replaced with e00, and (τ % X)#(e % e00), and reached from a uniform block (⊥ is in the S-stack). ATOM(τ 0) = X. B. Automated Mode Selection Insertion where ATOM(τ) is defined as τ, except that it is defined as ATOM(τ 0) if τ = mcasehτ 0i. The syntax we introduced earlier requires programmers to select mode cases explicitly through the select expression. C. Type Checking For example, to assign a variable y of mcasehinti type to Type checking is defined over the post-translation programs variable x of int type, programmers need to write x = select y. where calib and select expressions are explicit. It is largely This can be an onerous task for programmers, especially for standard. The subtyping relation is defined to be identical as incremental programming, where programmers start with a τ the << relation. For {m1 : e1; ... mn; en} , we require the type program written in an existing language, and incrementally of ei for 1 ≤ i ≤ n be a subtype of the declared type τ. “try out” new language abstractions. An Eco programmer may start with a Java program, and alter a variable from, say, V. PROGRAMMING IDIOMS holding a Res(1024, 768) object to the mode case we We now summarize common idioms we encountered while used in Figure 2. If explicit select is needed, the programmer programming in Eco. Broadly, the summary may serve as would have to manually insert a select expression for every a first step toward understanding design patterns and micro- occurrence of such variables in a sustainable block where the patterns of sustainable software. mode case is meant to be selected. We define a simple compiler transformation to relieve the A. Abstract Supply Units programmers of the burden of explicitly declaring select The sugared syntax bsupply use battery capacity (mwh) expressions. The key insight is that Eco as a strongly typed as the unit of supply, and syntax tsupply uses temperature language provides sufficient type information to compare both in Celsius. These units are not hardcoded in Eco. More the sending and the receiving ends of a data flow. For example, generally, an Eco programmer may choose any unit intuitive if a programmer writes x = y in the program, and variable y is and accurate for her sustainability management, as long as of mcasehinti type and variable x is of int type, our compiler such values can be obtained from underlying OS and hardware. transformation algorithm will transform it into x = select y. For example, popular battery-powered consumer computers More generally, the transformation is hinged upon the (laptops and smartphones) typically come with power man- definition of predicate (τ % τ 0)#(e % e0), which says an agement modules that can report the remaining operating time expression e of type τ should be transformed to e0 if it appears (or remaining percentage). A sustainable block that should at a program point expecting an expression of type τ 0. The consume no longer than 20% of the remaining operating time predicate holds iff either of the two holds: can be programmed as: 1 double budget = MAX; 1 i n t workdone = 0; 2 o l d = b a t t e r y ; 2 i n t workleft = IMGS ∗ r e s . x ∗ r e s . y ; 3 sustainable { 3 sustainable { 4 f o r ( i n t num = 0 ; num < IMGS; num++) { 4 f o r ( i n t num = 0 ; num < IMGS; num++) { 5 i f ( num == 0.1∗IMGS) { 5 ... 6 budget = ( b a t t e r y − o l d ) ∗ 9 ; 6 f o r ( i n t i = 0 ; i < IMAX; i ++) { 7 } 7 f o r ( i n t j = 0 ; j < JMAX; j ++) { 8 ... 8 ... 9 } 9 }} 10 } 10 workdone+= IMAX ∗ JMAX; 11 bsupply ( budget ) 11 workleft = (IMGS−num ) ∗ IMAX; JMAX; 12 demand (...) −> (...); 12 images[num] = image; 13 } 14 } 15 bsupply (PER ∗ BUDGET) Fig. 5. Revisable Budget 16 demand (workdone + workleft) −> (workleft );
1 sustainable { 2 double startROT = 0.2 ∗ getROT ( ) ; 3 ... Fig. 6. Adaptive Demand Characterization 4 } 5 (< startROT; startROT − getROT(); ...; ... >) C. Revisable Budget where getROT queries the system battery management mod- In Eco, both supply sum and supply gauge are expressions ule for the remaining operating time. reevaluated every time a calibration is performed. This implies In the real world, the suitable unit to report battery State- the budget (the value of what the supply sum expression of-Charge (SoC) [14] is dependent on many factors, such as evaluates to) does not need to remain constant throughout the (i) the characteristics of batteries, e.g. lithium-based or nickel- execution of the sustainable block. This feature can be useful based; (ii) the support of OS, e.g. ACPI-compliant systems to adaptively set the budget. For example, a programmer may 1 and different vendor extensions (such as BatteryService not know at the beginning what a “fair” budget would be, and in Android); (iii) the estimation algorithms. The more user- she can “test run” a portion of the program to find out and friendly metrics—remaining percentage, or remaining operat- reset the supply budget. Consider the example in Figure 5. ing time—are in fact derived metrics from lower-level battery Here, the program decides to executes 10% of the images, status data e.g., voltage level, current level, and coulomb and calculate the budget for the remaining 90% of the image counts [14]. Under the backdrop of this diverse and fast- processing accordingly. changing landscape, the abstraction provided by Eco main- More broadly, revisable budget programming pattern may tains a level of stability in the presence of technology changes. also be useful in (1) energy-aware systems relying on renew- able energy (e.g., solar), where supply change is not monotone B. Fixed Supply Characterization as the sustainable block executes; (2) systems with adaptive cooling devices, where temperature change may also follow Various forms of fixed battery budget characterization can complex patterns. be directly supported:
• fixed absolute battery budget, e.g., bsupply(20000) says D. Adaptive Demand Characterization the execution can consume up to 20000mwh of battery. Just like supply, demand sum and demand gauge are also • fixed relative battery budget, e.g., bsupply(0.2 ∗ battery) expressions that are reevaluated upon calibration. This allows says the execution can consume up to 20% of the remain- programmers to adaptively adjust the demand during the ing battery. sustainable block execution. For instance, Figure 6 shows a • maximum battery budget: e.g., bsupply(battery) says the refined version of Figure 2, where both the size of the overall execution can as much as the entire remaining battery. demand (i.e., what the demand sum evaluates to) and the Analogously, simple forms of temperature budget charac- size of the remaining demand (i.e., what the demand gauge terization are supported: evaluates to) may be adjusted. Here, we not only consider the number of images as demand indicators, but also the • fixed temperature threshold, e.g., the use of tsupply(70− number of pixels in the images. In the new scheme, the temperature) says the execution should not increase the ◦ change of resolution would alter both the size of the overall CPU temperature to more than 70 C. demand and the size of the remaining demand, because the • fixed temperature increase, e.g., tsupply(20) says the adoption of a lower resolution in rendering an image resulted execution should not increase the CPU temperature by ◦ in both the slower-than-expected growth for completed work more than 20 C. (workdone), and the reduction of the projected work ahead • fixed temperature increase ratio, e.g., tsupply(1.1 ∗ (workleft). temperature) says the execution should not increase the CPU temperature by more than 10%. E. Non-Linear Behaviors Battery-powered computer users often observe that the same 1http://developer.android.com program execution that reduces battery from 80% to 78% normalized remaining supply normalized remaining demand normalized remaining supply normalized remaining demand normalized remaining supply normalized remaining demand % % % 100 100 100 90 90 90 80 80 80 70 70 70 60 60 60 50 50 50 40 40 40 30 30 30 20 20 20 10 10 10 0 0 0 1 101 201 301 401 501 601 701 801 901 1001 1101 1201 1301 1401 1501 1601 1701 11 111 211 311 411 511 611 711 811 911 1011 1111 1211 1311 1 101 201 301 401 501 601 701 801 901 1001 Time(second) Time(second) Time(second) Fig. 7. sunflow (PER = 0.9) Fig. 8. sunflow (PER = 0.7) Fig. 9. sunflow (PER = 0.5) may reduces the same battery from 5% to 1%. Such non- a financial simulation from the Java Grande benchmark suite, linear battery behaviors are generally minimized by built- (4) xalan,6 an XSLT processor that converts XML docu- in OS/firmware estimators for new batteries, but they may ments, and (5) rasterizer, from the batik7 distribution, become more pronounced as batteries age. If high precision on that rasterizes SVG files. Our main selection criterion is battery supply is needed, such variations should not be ignored diversity, covering domains such as graphics, web, statis- and can be modeled in Eco as: tics, program transformation, and data transformation. These
1 sustainable { benchmarks cover a diverse range of applications to support 2 double s t a r t B = 0.2∗ getB ( ) ; variability in program behaviors, such as image resolution in 3 ... 4 } sunflow, URL request intervals in jspider, sampling size 5 supply (startB) (startB − redress(getB())) in montecarlo, and rasterization quality in batik. Several 6 demand (...)(...) selected benchmarks appeared in Dacapo8 benchmark suite. redress where is a custom-defined function mapping read- All experiments were performed on a Intel 2.53GHz Duo getBP ings from to the “compensated” values. For example, core CPU laptop with 8GB RAM. one simplistic redress function would be to map value b to b if b ≥ 0.2 and b to 0.9 × b otherwise. As energy- C. Battery-Aware Programming aware programming becomes more prevalent, we envision We modified the Java sunflow benchmark with Eco such “redress” functions would be part of the “battery profile” syntax. The rendering logic in sunflow resembles the code available to end programmers as library APIs. snippet in Figure 6. Our benchmarking execution renders 9 A similar programming idiom can be applied for non-linear images (IMGS=9), and the resolution and depth are imple- thermal behaviors. According to solid matter physics, the mented as first-class mode cases with identical definitions as ◦ ◦ energy to increase the temperature from 30 C to 35 C and in Figure 2. ◦ ◦ that from 300 C to 305 C significantly differ. (The range of We first execute the unmodified Java program and use its operating temperatures for CPUs is usually much narrower, so battery consumption as the baseline supply. This number is the non-linear effect in this area is relatively small.) used for setting the BUDGET constant in Figure 6. In our exper- The same idea can be applied to demand characterization. iment, BUDGET = 20970mWh. We execute the Eco program Non-linear behaviors can be supported when redress is not with 90%, 70%, 50% of the BUDGET. It is worth pointing a linear function. out that the experiment process described here is only meant for inducing “threshold behaviors”, e.g., the program running VI.IMPLEMENTATION AND EVALUATION with “just enough” battery, or “slightly inadequate” battery, or A. Implementation “significantly inadequate” battery. An Eco programmer does Eco is implemented on top of the Polyglot compiler frame- not need to profile in this manner (or worse, plugging 20970 work 2.5 [28], as an extension to Java. The battery data was into the source code). The more intuitive programming idioms queried through Advanced Configuration and Power Interface were described in Section V. (ACPI) [1] and read by the program. The CPU temperature The time series of supply gauage (blue lines) and demand was queried with the CoreTemp2 API, in Celsius. CoreTemp gauge (red lines) for the sunflow executions with 90%, 70%, collects data directly from a Digital Thermal Sensor (DTS) 50% of the BUDGET were shown in Figure 7, Figure 8, Fig- located in each individual processing core. There is no need ure 9, respectively. All data are normalized. All experiments for external measuring devices or external circuit located on are started with the same battery level. At any given time, if the motherboard to report temperature. the demand curve is (significantly) above the supply curve, the program runs in a “deficit.” A mode change will happen B. Benchmarks after the processing of the current task, in the hope that the We selected the following Java benchmarks and modified demand for the next task will go below the supply change. them into Eco: (1) sunflow,3 a rendering system that uses As one can see, battery supply change is near linear. The raytracing, (2) jspider,4 a web crawler, (3) montecarlo,5 change in demand happens at discrete time, since workdone and workleft are not updated until an image is processed. 2http://www.alcpu.com/CoreTemp 3http://sunflow.sourceforge.net/ 6http://xalan.apache.org/ 4http://j-spider.sourceforge.net/ 7http://xmlgraphics.apache.org/batik/ 5http://www.javagrande.org/ 8http://www.dacapobench.org/ % supply(5.6wh) demand quality of rasterization, as a larger height means a larger width 100 90 80 and therefore higher resolution. The mode case is defined by 70 60 height pixel as {hi : 12000; mid : 10000; lo : 8000}, 50 40 30 where 12000 is used for the original Java execution. As 20 10 Figure 10 suggests, Eco achieves the goal of sustainability 0 Time(second) 1 101 201 301 401 501 601 by matching supply and demand closely. Figure 11 shows the Fig. 10. batik: supply/demand (70% budget) adaptively selected resolutions based on the changes of supply and demand. Image height (pixel) 12000 Last, we modified montecarlo, where a mode case is 11000 defined to adjust the sample size. Specifically, the value in each 10000 9000 case member is the difference between the “perfect” sample 8000 7000 size (280,000) and the sample size being used for that mode. Time(second) 1 101 201 301 401 501 601 The larger sample size, the higher quality the output will be. Fig. 11. batik: image height (70% budget) We use a syntactic sugar to define this mode case (with a large number of cases whose mode names are implicit), in % 100 90 the same effect of defining {m0 : 0; ... mi : i × ∆; ... mn : 80 70 60 supply(1.6wh) n × ∆} where ∆ = 10, 000. In other words, our benchmark 50 demand 40 30 adjusts the sample size by the increment/decrement of ∆. The 20 10 0 Time(second) execution of the unmodified Java code (for Monte Carlo core 1 21 41 61 81 101 121 141 161 Fig. 12. montecarlo: supply/demand (80% budget) algorithm) consumes 2060mwh of battery (“the budget”). The Eco execution operates on of 80% of that budget, with results data size shown in Figure 12 and Figure 13. As Figure 12 suggests, Eco 300000 250000 again matches supply and demand closely. Figure 13 shows 200000 150000 100000 the change of sample size over time. 50000 0 Time(second) 1 21 41 61 81 101 121 141 161 D. Temperature-Aware Programming Fig. 13. montecarlo: sample size (80% budget) To demonstrate temperature-aware programming, we use xalan to transform 17 XML files with 8000 iterations. We Therefore, each “plateau” in the demand curve represents the modify the original Java program as follows. First, we set processing of one image. As high-resolution rendering takes a fixed temperature threshold to 60◦C. This is expressed as significantly longer time, the “width” of each “plateau” is tsupply(60 − temperature). Second, in between every other indicative of the operational mode. file transformation, we allow the CPU to sleep at a fixed Sustainability—the scenario where the supply consistently interval. A mode case is used for this sleep interval, set with meets the demand—is maintained in all three scenarios: ob- two case members: when the mode is hi, the interval is set serve the supply curve and the demand curve in all three at 4 milliseconds, whereas when the mode is lo, the interval figures follow similar patterns of decline. The following table is set at 10 milliseconds. reports the statistics of our experiments: Figure 14 demonstrates the temperature changes of xalan, PER supply set supply used # hi # mid # lo both in the Java execution and the Eco execution. As a bench- 0.9 188.6wh 186.0wh 5 4 0 mark, xalan involves intensive CPU-bound computations. 0.7 147.0wh 142.1wh 1 7 1 Without any sustainability management, the Java execution 0.5 104.8wh 103.3wh 1 2 6 drives the temperature over 60◦C within one minute (a rise Observe that in all cases, Eco runtime is capable of meeting of about 15◦C). The Eco execution on the other hand suc- the budget (i.e., the “supply used” is less than the “supply cessfully maintains the CPU temeperature within the threshold. set”). The #hi, #mid, #lo columns in the table list the Figure 15 may explain the fundamental difference between the number of images rendered with high/mid/low resolutions. two executions, showing different levels of CPU utilization Predictably, more images are rendered with lower resolutions (Y-axis, plotted with OS performance monitor). During the as the supply is set lower. Java execution, the CPU utilization is mostly 100%. The Eco Next, we designed a battery-aware variant of batik, pro- execution however regulates the CPU utilization at a much cessing 27 SVG files with the supply of 8050mwh × 70%. lower adaptive level. Similar to the fashion the sunflow experiment was con- The figures here also demonstrate the trade-off between structed, we first executed the unmodified Java program and temperature regulation and performance. Without any sleep, obtained the battery usage of 8050mwh, which we informally the Java execution is able to complete the transformation call “the budget.” The battery-aware variant thus runs on 70% within about half the time of the Eco execution (terminates of that budget. The adaptive behaviors are defined by a mode after around 301 seconds). This comes with no surprise: the case value for target image height. Since the image resolution latter execution intentionally slows down itself frequently. is adjusted by ratio, this value is strongly correlated with the Figure 16 demonstrates the change of sleep intervals over time. ̊C millisecond 70 % 12 100 10 65 90 80 70 8 60 JAVA 60 JAVA 50 6 55 ECO 40 ECO 30 4 50 20 10 2 0 45 Time(second) 0 Time(second) 1 51 101 151 201 251 301 351 401 451 501 551 601 651 Time(second) 1 51 101 151 201 251 301 351 401 451 501 551 601 651 1 51 101 151 201 251 301 351 401 451 501 551 601 651 Fig. 14. xalan: CPU temperature Fig. 15. xalan: CPU utilization Fig. 16. xalan: sleep interval
% ̊C 100 2500
70 90
65 80 2000 70 60 JAVA 60 JAVA 1500 JAVA 55 50 ECO ECO ECO 1000 50 40 30
45 Interval(millisecond) 500 20 40 Time(second) 10 Time(second) 0 1 76 151 226 301 376 451 526 601 676 751 Time(second) 0 1 76 151 226 301 376 451 526 601 676 751 1 76 151 226 301 376 451 526 601 676 751 Fig. 17. jspider: temperature Fig. 18. jspider: CPU utilization Fig. 19. jspider: sleep interval We also constructed a temperature-aware execution of with supply and demand is mostly known in OS research. jspider in Eco. Similar to xalan, the temperature is also Examples include resource management and scheduling for set at the fixed threshold of 60◦C. We employ a similar grid environment [6], device energy management [40], utility strategy for temperature control, by allowing the crawler to computing in clouds [7], energy distribution among users [27]. sleep at fixed intervals. Unlike xalan where each XML Recently, the supply/demand model is also used for perfor- file is processed in a relatively short period of time, each mance tuning [26]. Eco enriches the landscape of sustainable step in crawling—involving requesting a URL, parsing the computing by empowering programmers. webpage, and analyzing the links contained in the page— A number of programming models exist for developing takes significantly longer. This allows us to design with longer energy-aware software, such as Green [4], EnerJ [36], and intervals of sleeps (but much less frequent than xalan). The ET [10]. They do not offer fine-grained energy/temperature interval is implemented as a mode case, with hi mapping to budgeting to programmers, and do not focus on maintaining 0.5 second, mid to 1 second, and hi to 2 seconds. Figure 17 sustainability through programmer supply/demand characteri- shows the temperature results. Figure 18 shows the CPU zation. Beyond energy-aware computing, programming models utilization, and Figure 19 shows the interval change. Typical for self-adaptive systems (e.g., [8]) share a high-level design for a web crawler, there is no “completion” time unless the goal of Eco: promoting adaptiveness in the presence of user stops the execution. Our demand is set (and reset) at dynamic variations of software/system environments. fixed time intervals. As a result, all time series shown here Broadly, application-level energy management and opti- for jspider can be viewed as the first 800 seconds of an mization is an active area, with recent results diversely ranging (almost infinitely running) execution. from program analysis and optimization (e.g., [16], [5]), test- ing and debugging (e.g., [21], [2]), design patterns (e.g., [35], E. Programming Efforts [24]), decision framework (e.g., [25]), measurement and esti- The programming effort for Eco is mild, and the LOCs that mation support (e.g., [37], [17]), runtime support (e.g., [33]), involve Eco-specific changes are relatively small: and empirical studies (e.g., [30], [31], [23]). More broadly, there is a long history in VLSI, architec- LOCs sunflow jspider montecarlo xalan batik ture, and OS research to design and implement battery-aware original 30984 13986 3128 347801 325238 Eco changes 46 56 23 32 27 (e.g. [12]) or temperature-aware (e.g. [38]) computer systems. A fundamental challenge is the need to “predict the future,” Despite some benchmarks have high LOCs in their Java with solutions ranging from profiling and monitoring [11], versions, the changes involved for sustainable programming machine learning [9], to agent-based modeling [13]. Eco com- concentrate on a small number of files, typically the entry plements existing systems by bringing programmer knowledge points of core algorithms, and the variables representing the into the design space. adjustable parameters. The majority of development time was used in understanding existing benchmarks, and finding appro- VIII.CONCLUSION priate procedures/algorithms to support adaptive sustainable This paper describes Eco, a sustainable programming model programming. Once the algorithm of interest is identified, the for developing Java-like applications. With novel abstractions programming effort itself for developing the benchmarks we for supply and demand shaping, Eco brings programmers into experimented with — adding Eco-specific expressions into the loop of sustainability management and promotes energy- programs, and debugging — is small, usually in hours. aware programming and temperature-aware programming.
VII.RELATED WORK IX.ACKNOWLEDGMENTS Sustainable computing is an emerging topic in computer sci- We thank the anonymous reviewers for their useful com- ence. Within software engineering, support for sustainability ments, and Anthony Canino for his help improving the com- has appeared in requirements engineering [34], [29], [32] and piler and the benchmarks. This work is partially supported by software architecture [18], [20]. Modeling computer systems US NSF CCF-1054515. REFERENCES [21]L I,D.,JIN, Y., SAHIN,C.,CLAUSE,J., AND HALFOND, W. G. J. Integrated energy-directed test suite optimization. In ISSTA’14 (2014), [1] Advanced configuration and power interface, http://www.acpi.info. pp. 339–350. [2] Carat, http://carat.cs.berkeley.edu. [22]L ISKOV, B. Distributed programming in argus. Commun. ACM 31, 3 [3] Data centers look for lower-emission cooling, http://www.nytimes.com/ (1988), 300–312. 2011/06/20/business/global/20green.html. [23]L IU,K.,PINTO,G., AND LIU, Y. D. Data-oriented characterization of [4]B AEK, W., AND CHILIMBI, T. M. Green: a framework for supporting application-level energy optimization. In FASE 2015 (Apr. 2015). energy-conscious programming using controlled approximation. In [24]L IU, Y. D. Energy-efficient synchronization through program patterns. PLDI’10 (2010), pp. 198–209. In First International Workshop on Green and Sustainable Software, [5]B ARTENSTEIN, T., AND LIU, Y. D. Green streams for data-intensive (GREENS 2012) (2012), pp. 35–40. software. In ICSE’13 (May 2013). [25]M ANOTAS,I.,POLLOCK,L., AND CLAUSE, J. Seeds: A software [6]B UYYA,R.,ABRAMSON,D.,GIDDY,J., AND STOCKINGER, H. Eco- engineer’s energy-optimization decision support framework. In ICSE’14 nomic models for resource management and scheduling in grid comput- (2014), pp. 503–514. ing. Concurrency and computation: practice and experience 14, 13-15 [26]M ITCHELL,N., AND SWEENEY, P. F. On the fly capacity planning. In (2002), 1507–1542. OOPSLA ’13 (October 2013). [7]B UYYA,R.,YEO,C.S., AND VENUGOPAL, S. Market-oriented [27]N ARASIMHAN,S.,MCINTYRE,D.R.,WOLFF, F. G., ZHOU, Y., cloud computing: Vision, hype, and reality for delivering it services as WEYER,D.J., AND BHUNIA, S. A supply-demand model based computing utilities. In Proceedings of the 2008 10th IEEE International scalable energy management system for improved energy utilization Conference on High Performance Computing and Communications efficiency. In International Conference on Green Computing (2010), (2008), HPCC ’08, pp. 5–13. IEEE, pp. 97–105. [8]C HENG, S.-W., AND GARLAN, D. Stitch: A language for architecture- based self-adaptation. J. Syst. Softw. 85, 12 (Dec. 2012), 2860–2875. [28]N YSTROM,N.,CLARKSON,M.R., AND MYERS, A. C. Polyglot: An extensible compiler framework for java. In International Conference on [9]C HUNG, E.-Y., BENINI,L., AND DE MICHELI, G. Dynamic power Compiler Construction management using adaptive learning tree. In Proceedings of the 1999 (Apr. 2003), pp. 138–152. IEEE/ACM international conference on Computer-aided design (1999), [29]P ENZENSTADLER,B., AND FEMMER, H. A generic model for sustain- ICCAD ’99, pp. 274–279. ability with process- and product-specific instances. In Proceedings of the 2013 Workshop on Green in/by Software Engineering (2013), GIBSE [10]C OHEN,M.,ZHU,H.S.,EMGIN,S.E., AND LIU, Y. D. Energy types. In OOPSLA ’12 (October 2012). ’13, pp. 3–8. INTO ASTOR AND IU [11]C ONTRERAS,G., AND MARTONOSI, M. Power prediction for Intel [30]P ,G.,C , F., L , Y. D. Mining questions about XScale processors using performance monitoring unit events. In Pro- software energy consumption. In MSR’14 (2014), pp. 22–31. ceedings of the 2005 international symposium on Low power electronics [31]P INTO,G.,CASTOR, F., AND LIU, Y. D. Understanding energy and design (2005), ISLPED ’05, pp. 221–226. behaviors of thread management constructs. In OOPSLA’14 (2014). [12]F LINN,J., AND SATYANARAYANAN, M. Managing battery lifetime with [32]R ATURI,A.,PENZENSTADLER,B.,TOMLINSON,B., AND RICHARD- energy-aware adaptation. ACM Trans. Comput. Syst. 22, 2 (May 2004), SON, D. Developing a sustainability non-functional requirements frame- 137–179. work. In GREENS 2014 (2014), pp. 1–8. [13]G E, Y., QIU,Q., AND WU, Q. A multi-agent framework for thermal [33]R IBIC,H., AND LIU, Y. D. Energy-efficient work-stealing language aware task migration in many-core systems. IEEE Trans. Very Large runtimes. In ASPLOS (2014), pp. 513–528. Scale Integr. Syst. 20, 10 (Oct. 2012), 1758–1771. [34]R OHER,K., AND RICHARDSON, D. Sustainability requirement patterns. [14]G LOVER,J.D.D., AND SARMA,M.S. Power System Analysis and In Requirements Patterns (RePa), 2013 IEEE Third International Work- Design, 3rd ed. Brooks/Cole Publishing Co., Pacific Grove, CA, USA, shop on (July 2013), pp. 8–11. 2001. [35]S AHIN,C.,CAYCI, F., GUTIERREZ´ ,I.L.M.,CLAUSE,J.,KIAMILEV, [15]G RAY, J. The transaction concept: virtues and limitations (invited paper). F. E., POLLOCK,L.L., AND WINBLADH, K. Initial explorations on In Proceedings of the seventh international conference on Very Large design pattern energy usage. In First International Workshop on Green Data Bases - Volume 7 (1981), VLDB ’81, pp. 144–154. and Sustainable Software, (GREENS 2012) (2012), pp. 55–61. [16]H AO,S.,LI,D.,HALFOND, W. G. J., AND GOVINDAN, R. Estimating [36]S AMPSON,A.,DIETL, W., FORTUNA,E.,GNANAPRAGASAM,D., mobile application energy consumption using program analysis. In ICSE CEZE,L., AND GROSSMAN, D. EnerJ: Approximate data types for ’13 (2013), pp. 92–101. safe and general low-power computation. In PLDI’11 (June 2011). [17]H INDLE,A.,WILSON,A.,RASMUSSEN,K.,BARLOW,E.J.,CAMP- [37]S EO,C.,MALEK,S., AND MEDVIDOVIC, N. An energy consumption BELL,J.C., AND ROMANSKY, S. Greenminer: A hardware based framework for distributed java-based systems. In ASE ’07 (2007), mining software repositories software energy consumption framework. pp. 421–424. In MSR 2014 (2014), pp. 12–21. [38]S KADRON,K.,STAN,M.R.,HUANG, W., VELUSAMY,S.,SANKARA- [18]K OZIOLEK, H. Sustainability evaluation of software architectures: NARAYANAN,K., AND TARJAN, D. Temperature-aware microarchitec- A systematic review. In Proceedings of the Joint ACM SIGSOFT ture. In ISCA ’03 (2003), pp. 2–13. Conference – QoSA and ACM SIGSOFT Symposium – ISARCS on [39]S ORBER,J.,KOSTADINOV,A.,GARBER,M.,BRENNAN,M.,COR- Quality of Software Architectures – QoSA and Architecting Critical NER,M.D., AND BERGER, E. D. Eon: a language and runtime system Systems – ISARCS (2011), QoSA-ISARCS ’11, pp. 3–12. for perpetual systems. In SenSys, pp. 161–174. [19]K ULKARNI,A.,LIU, Y. D., AND SMITH, S. F. Task types for pervasive [40]Z ENG,H.,ELLIS,C.S.,LEBECK,A.R., AND VAHDAT, A. Ecosystem: atomicity. In OOPSLA’10 (October 2010). managing energy as a first class operating system resource. In ASPLOS [20]L AGO, P., JANSEN, T., AND JANSEN, M. The service greenery- (2002), pp. 123–132. integrating sustainability in service oriented software. In International [41]Z HU,H.S.,LIN,C., AND LIU, Y. D. A programming Workshop on Software Research and Climate Change (WSRCC), co- model for sustainable software (technical report), available online at located with ICSE (2010), vol. 2. https://github.com/pl-eco/ECO, 2015.