Sustainable Programming with Eco

Haitao Steve Zhu Chaoren Lin Yu David LiuDepartment of Computer Science

SUNY BinghamtonBinghamton NY 13902, USA

{hzhu1,clin18,davidL}@binghamton.edu

ABSTRACTThis paper presents Eco, a novel energy-aware program-ming model centering around sustainability. A sustainableprogram adaptively adjusts its own behaviors to stay ona given energy budget, avoiding both deficit that wouldlead to battery drain or CPU overheating, and surplus thatcould have been used to improve the quality of the pro-gram output. Sustainability management in Eco is builton a key insight where sustainability is viewed as a formof supply and demand matching, and a sustainable pro-gram consistently maintains the equilibrium between supplyand demand. Concretely, Eco introduces a novel languageabstraction—sustainable blocks—to achieve fine-grained pro-grammable sustainability. Eco is implemented as a minimalextension to Java, and we validate its design by upgrad-ing real-world Java programs, enabling two crucial featurestoward energy-aware software: battery awareness and tem-perature awareness.

1. INTRODUCTIONModern computing platforms move forward in two tra-

jectories: they either go “nimble,” or go “mighty.” Nimbleor mighty, a common hurdle lies ahead: energy consump-tion. “Nimble” computers—such as RFIDs, wearable elec-tronics, smartphones, tablets, and laptops—often operate onbattery. “Mighty” computers—represented by data centers,cloud servers, and many-core clusters—are not only power-hungry, but also overheating-anxious, with cooling taking upto 35% of their operational costs [3]. There is a growing in-terest in the software community to address these challenges,with innovations through software design methodologies [19,21, 26, 28, 2], programming models [9, 27, 4, 30], and pro-gram analysis [5, 15]. A common theme of these efforts is toimprove software energy efficiency, i.e., maximizing energysavings.

The focus of this paper is a much less explored property:sustainability, i.e. the ability for a program to “stay on bud-get,” neither yielding deficit nor surplus. At the first glance,

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.Copyright 20XX ACM X-XXXXX-XX-X/XX/XX ...$15.00.

the goal of maintaining sustainability is counter-intuitive:wouldn’t it be more desirable to yield as much surplus aspossible? Ideally, yes, but free lunch is over. The most ef-fective energy management strategies are known to be trade-offs, such as sacrificing performance [25], data precision [27],and quality of service [4]. To balance the trade-off, we be-lieve it is more sensible for an energy-aware program to nei-ther squander nor skimp, a design philosophy we term sus-tainable programming.

Our concrete proposal is Eco, a novel and simple program-ming model to help developers construct sustainable soft-ware by design, centering around three language features:

1. sustainable blocks: an Eco programmer can associateany code fragment with an energy-related budget—such as the execution of the code fragment does notconsume more than 20% of remaining battery or raisetemperature by 10◦C—and the language runtime makesbest effort to adjust program behaviors to meet thebudget.

2. first-class mode cases: Eco programmers can define al-ternative program behaviors as first-class values, suchas a value that captures the intention of setting theimage resolution to 1024×768 when an energy budgetcan be easily met, and to 800× 600 otherwise.

3. uniform blocks: Eco allows programmers to maintainthe application-specific consistency in the presence ofautomatic program behavior adaption, such as pre-venting the change of image resolution half way throughprocessing one image.

Eco is built upon an intuitive view that sustainability canonly be achieved through recurrent and dynamic negotia-tion between supply and demand. Even though supply anddemand modeling is not new in computer science [6, 31,7, 23, 22], we believe Eco is the first system that buildssupply and demand directly into programming models andbring “programmable sustainability” to modern software en-gineering. Among the numerous energy/thermal manage-ment systems [11, 29, 31, 8, 10, 12, 23]—most from VLSI,architecture, and OS communities—Eco is distinctive in itsattempt to combine the strengths of the human (the pro-grammer) and the machine (the language runtime):

1. programmable supply/demand characterizations (or, howthe human helps the machine): To a sustainable block,an Eco programmer provides a supply characterizationto specify the application-specific energy budget, and a

demand characterization to help the program runtimeassess the “work” progress of the sustainable block.

2. automated supply/demand negotiation (or, how the ma-chine helps the human): with the supply/demand char-acterizations, the Eco language runtime automaticallymonitors the changes in supply and demand as thesustainable block is executed, and adaptively adjustprogram behaviors to meet the goal of sustainability.Programmers do not need to consider when to adjust,what to adjust to, and how to maintain sustainabilityand uniformity.

In summary, this paper makes the following contributions:

• It calls for the need for sustainable programming inenergy-aware software development, and describes thefirst programming language to make sustainability pro-gramable.

• It provides a novel programming abstraction wheresustainability is modeled as supply/demand character-ization and negotiation.

• It supports a recurring theme in software-based energymanagement — alternative program behaviors for dif-ferent energy needs – with first-class mode cases thatsupports extensible programming.

• It defines the Eco language in a rigorous setting, with aformal model that captures the essence of sustainableprogramming.

• It reports a prototype implementation, and validatesthe language design through extending real-world ap-plications with the ability of battery awareness andtemperature awareness.

2. SUSTAINABLE PROGRAMMING BY EX-AMPLE

We use a simple raytracing example in Figure 1 to demon-strate the basic ideas of sustainable programming. Raytrac-ing is a technique in rendering where an object in the formof a Model is rendered into an Image—a 2D array of col-ored pixels—based on the Rays cast from the Camera to theobject.

Eco is an extension to Java, with several notable featureswe highlight next.

Sustainable blocks.An energy-conscious programmer may declare the most

expensive part of her program in sustainable blocks. In thisexample, the block encloses the ray tracing for IMGS numberof images, as shown between Line 22 and Line 41. The pro-grammer can set a budget for executing this code fragmentthrough supply characterization: in Line 40, the budget (alsoknown as supply sum) is set at 20% of the remaining battery.To help the language runtime correlate the change in bat-tery over time and the progress of the program execution,Eco programmers are asked to provide a “progress indicator”through demand characterization. In this oversimplified ex-ample, the programmer just says that the demand sum—i.e.the overall number of units of work—is IMGS (the number ofimages), and at a given moment during the sustainable block

1 mode { l o <: mid } ;2 mode { mid <: h i } ;3

4 class Raytracer {5 mcase<Res> r e s = {6 l o : new Res (640 , 480 ) ;7 mid : new Res (800 , 600 ) ;8 hi : new Res (1024 , 768 ) ;9 } ;

10

11 mcase<int> depth = {12 l o : 10 ;13 mid : 20 ;14 hi : 30 ;15 } ;16

17 Ray [ ] [ ] getView (Camera camera , Res r e s ) { . . . }18

19 Image [ ] run (Camera camera , Model [ ] models ) {20 Image [ ] images ;21 int IMAX, JMAX, IMGS = 100 ;22 sustainable {23 for ( int num = 0 ; num < IMGS; num++) {24 uniform {25 Ray [ ] [ ] view = getView ( camera , r e s ) ;26 Image image = new Image ( r e s ) ;27 IMAX = re s . y ;28 JMAX = re s . x ;29 }30 for ( int i = 0 ; i < IMAX; i++) {31 for ( int j = 0 ; j < JMAX; j++) {32 image . s e tCo lo r ( i , j ,33 view [ i ] [ j ] . t r a c e ( models [num] , depth )34 ) ;35 }36 }37 images [num] = image ;38 }39 }40 bsupply ( 0 . 2 ∗ battery )41 demand (IMGS) −> (IMGS − num) ;42 return images ;43 }44 }45 class Model { . . . } // model to be rendered46 class Camera { . . . } // camera for rendering47 class Image { . . . } // 2D array of co lor p i x e l s48 class Ray { . . . } // ray49 class Res { . . . } // re so lu t i on

Figure 1: A Battery-Aware Raytracing Application

execution, the demand gauge—the indicator for the remain-ing number of units of work—is dependent on the loop indexnum, i.e. IMGS - num. Based on supply characterization anddemand characterization, Eco introspects

• the proportion of remaining demand, i.e., demand gaugerelative to demand sum) and

• the proportion of remaining supply, i.e., remainingbattery supply relative to overall battery supply

at various “checkpoints” during the execution of the sustain-able block, and deem the execution: (i) sustainable if the twoare on similar levels; (ii) deficit if the former significantly ex-ceeds the latter; (iii) surplus if the latter significantly exceedsthe former.

Modes and First-Class Mode Cases.Whenever deficit or surplus happens, the program adjusts

itself, guided by specifications of modes and first-class modecases.

Borrowed from a previous work [9], modes are a discretecharacterization of energy-adaptive states. In Line 1 and

Figure 2: Results from Mode Changes at ArbitraryTime

Line 2, the program defines three modes, lo, mid, and hi,indicating the program may function under three differentstates of adaption. In Eco, modes form a total order, withlo/mid/hi in the example aligned with the intuition that theresulting code is likely to consume the least/average/mostenergy, respectively.

Modes matter in Eco because they play a central role inthe design of mode cases. In a nutshell, a mode case is adata-centric way to define alternative behaviors in the pres-ence of energy adaption. In the example, two mode casesare defined as fields: (i) the res field in Line 5 that says theRaytracer may use the resolution of 640 × 480 when pro-gram is executing the lo mode, 800× 600 in the mid mode,and 1024×768 in the hi mode; (ii) the depth field in Line 11that says the depth of Raytracer—a key parameter to con-trol the quality of raytracing—may be either 10, 20, or 30,depending on the mode of the executing program. Modecases in Eco are first-class values: they can be assigned tovariables, passed around as method parameters, or stored infields.

To tie everything together, the executing sustainable block“downgrades” the mode of its execution whenever deficithappens—picking a precedent in the total order—and themode case used in that block can be intuitively viewed asautomatically destructed based on the new mode. For ex-ample, the mode case of depth under the execution of mid

mode would be destructed into 20. The scenario for surplusis similar, except that the sustainable block “upgrades” itsmode. Overall, the described behavior here is aligned withour intuition of sustainability: the program adapts to theless energy-consuming behavior when it runs into a deficitand to the more energy-consuming behavior when it runsinto a surplus.

Uniform Blocks.Coming with the flexibility of first-class mode cases is a

design challenge: allowing for mode case destruction at arbi-trary time may yield results unacceptable to programmers.For instance, had we allowed the image resolution to changehalf way through raytracing an image, the program mayproduce a picture such as Figure 2, whose uneven renderingmay unsettle (some) programmers.

An Eco programmer may choose to declare a block ofcode within a sustainable block as uniform, as in Line 24 toLine 29. This precludes mode change from happening duringthe execution of the enclosed code block. This consistency-preserving construct is reminiscent of the property of atom-

P ::= 〈C; D〉 programC ::= class X extends Y {F M } classF ::= τ fd fields

M ::= τ md(τ x){e} methodse ::= je expression

| {e} J e−> e Ks J e−> e Kd| {m : e}| uniform{e}

je ::= n | x | e.fd | e.fd = e Java expression| e.md(e) | new X

| τ x = e; e′

τ ::= num | X |mcase〈τ〉 typeD ::= mode m <: m mode declarationX, Y ∈ CN ∪ {Object} class namex, y ∈ VN ∪ {this} variable namefd ∈ FN field namemd ∈ MN method namem ∈ MDN mode namen ∈ NUM numeric constant

Figure 3: Eco Core Abstract Syntax

icity [14, 20, 18].

Battery-Awareness and Temperature Awareness.The example here is aware of battery states. With mini-

mal changes, the same program can turn into a temperature-aware one: by simply changing Line 40 to tsupply(10), thesame sustainable block is to be executed with a (tempera-ture) budget of 10◦C, i.e. not raising CPU temperatures bymore than 10◦C.

As we shall see, both bsupply and tsupply are syntacticsugars encodable by a more general form of supply char-acterization. Just as demand characterization includes de-mand sum and demand gauge, supply can be symmetricallycharacterized by supply sum and supply gauge.

3. ECO LANGUAGE DESIGN

3.1 Abstract SyntaxThe core abstract syntax of Eco is defined in Figure 3.

As Eco is an extension to Java, the formal core here is builtupon Featherweight Java (FJ) [17]. Standard “overline” no-tation • represents a sequence of •’s. A program consists ofa list of classes (C), together with a list of mode declarations(D). Selected Java expressions (je) are slightly richer thanFJ, including numeric constants n, variables x, self referencethis, field read e.fd, field write e.fd = e, method invocatione.md(e), instantiation new X, and variable declaration andcontinuation τ x = e; e′. Pre-defined class name Object isthe root class. A program bootstraps from the main methodof a class named Main, which has no fields. For simplicity, wedo not formalize constructors and multi-argument methods.

Expression sustainable{e} supply e1−> e′1 demand e2−>e′2, or abbreviated as {e} J e1−> e′1 Ks J e2−> e′2 Kd, definesa sustainable block for e where e1 is called the supply sum,e′1 is called the supply gauge, e2 is called the demand sum,e′2 is called the demand gauge. Expression {m : e} representsa mode case, where each element m : e in the sequence —which we call a case member —intuitively says that undermode m, the mode case should behave as a value computed

by e. Expression uniform{e} defines a uniform block for e.Given getB and getT are (effectful) 0-arity functions that

can read the current battery capacity and current CPU tem-peratures, the sugared syntax we used in Section 2 can bedesugared as in Figure 4.

For any program P = 〈C; D〉, we require the modes de-fined in D form a total order defined by <:. Formally, thismeans the reflexive and transitive closure of relation R isa total order, where R is the smallest relation containingelements 〈m; m′〉 where mode m <: m ∈ D. We further callthe least element and greatest element in the total orderthe least mode and greatest mode respectively. Implicitlyparameterized by D, unary operators ↑ and ↓ are standardsuccessive and precedent operators over total order. Fur-

thermore, ↑ m def= m if m is the greatest mode and ↓ m def

= m

if m is the least mode.Since our examples frequently use values of primitive types,

numeric values n are explicitly supported, but implicit box-ing and unboxing are used when they are assigned, stored,and passed around. For instance, the Eco programmer ex-pression x = 2 is encoded as x.val = 2, and primitive valueassignment x = y is encoded as x.val = y.val, where val isa built-in field of the primitive type at concern. As we shallsee, this treatment helps us unify the discussion of seman-tics.

3.2 Supply/Demand MatchingThe matching between supply and demand is captured

by the following predicates, where numeric value n1 corre-sponds to supply sum, n′1 to supply gauge, n2 to demandsum, and n′2 to demand gauge, and ε is a small positivenumeric constant close to 0:

match(n1, n′1, n2, n

′2)

def= |n

′1n1− n′

2n2| ≤ ε

surplus(n1, n′1, n2, n

′2)

def=

n′1n1− n′

2n2

> ε

deficit(n1, n′1, n2, n

′2)

def=

n′2n2− n′

1n1

> ε

Intuitively, the supply and the demand match when the

proportion of remaining supply (n′1n1

) and the proportion of

remaining demand (n′2n2

) are close in range. If the former sig-nificantly exceeds the latter, we have a“surplus”of supply. Ifthe latter significantly exceds the former, we have a “deficit”of supply. Observe that in real number domains, equalityis generally established through approximity in distance. Inpratice, a small yet not minuscule ε can help increase the sta-bility of the system—otherwise every supply/demand com-parison would yield either a surplus or deficit. Eco languageruntime selects ε = 0.1: the program is considered “sustain-able” if the remaining proportions of supply and demand arewithin ±10% difference.

With this we can define convenience function on modeadjustment:

adjust(m, v1, v′1, v2, v

′2)

def=

8<: m if match(v1, v′1, v2, v

′2)

↓ m if deficit(v1, v′1, v2, v

′2)

↑ m if surplus(v1, v′1, v2, v

′2)

The language is neutral on the concrete “unit” of the sup-ply or demand. For instance, a supply can either be bat-tery capacity in joules, battery capacity in milliwatt hour,or battery remaining time in seconds, or temperature in cel-sius, etc. The only requirement to keep the definitions above

sound is the supply sum and supply gauge refer to the sameunit. Similarly, the programmer is also at the liberty to de-cide on the “unit” of demand, as long as the demand sumand the demand gauge refer to the same unit. We will comeback to this topic in Section 5.2.

3.3 Language SemanticsWe now informally describe the dynamic behaviors of Eco

programs, with a formal definition of operational semanticsin the Appendix. Runtime values v are either a numeric n,an object reference o, or a first-class mode case {m : v}. Theruntime configuration of an Eco program consists of:

• a heap H, defined as a mapping from object referencesto field stores that represent the state of the objects.

• a context K, defined as a sequence of elements eitherin the form of ` : m or of ` alone, where ` is the programlabel for sustainable/uniform blocks, and m is the mode

The evaluation order of Eco is consistent with Java. Forexpression {m : e}, all case expressions e1, . . . , en are evalu-ated at mode case definition time.

Sustainable/Uniform Block Entry/Exit.The runtime maintains context K as a stack with several

simple rules:

R1 When a sustainable block is encountered, entry ` : mis pushed onto K (adding to the right most positionof the sequence), where ` is the program label of theblock, and m is the “current” mode before block entry,defined shortly;

R2 When a uniform bloack is encountered, entry ` is pushedonto K where ` is the program label of the block;

R3 Upon block exit, the stack top is popped (removingfrom the right most position of the sequence).

Together with one rule for bootstrapping:

R4 When a program bootstraps, set K as `boot : m, wherem is the greatest mode

With R4, code not in any sustainable block runs underthe greatest mode: they should not subject to sustainabil-ity management anyways. The informal notion of “currentmode”in R1 is defined by convenience function current(K),as m where (` : m) is an element in K, and there does notexist any `′ : m′ in K to its right in the sequence. Com-bining this with R1 and R4, it means when a non-nestedsustainable block is first encountered, the current mode is(initially) the greatest mode; when a nested block is encoun-tered, the current mode is (initially) the current mode of theblock immediately enclosing the nested block.

Mode Case Destruction.Mode cases are destructed based on the current mode of

the enclosing sustainable block. We delay the destructionuntil an evaluation must make the destruction to progress,so that the values can be first-class as long as possible. Thismeans a first-class mode case is not destructed until it servesas the target of field access or messaging. To define this be-havior, let us define pmq |v as vi where v = {m1 : v1, . . . , mn :

batterydef= getB()

sustainable{e} bsupply e1 demand e2−> e′2def= num x = getB(); num y = e1;

{e} J y−> (y− x + getB()) Ks J e2−> e′2 Kdtemperature

def= getT()

sustainable{e} tsupply e1 demand e2−> e′2def= num x = getT(); num y = e1;

{e} J y−> (y− x + getT()) Ks J e2−> e′2 Kd

Figure 4: Syntax Desugaring

vn} and mi is the least mode among {m1, . . . , mn} that areequal to or greater than m according to the total order de-fined by the program.

R5 Given v as a mode case value, expression v.fd evaluatesto v0.fd, whereK is the context and v0 = pcurrent(K)q |v.Similarly, v.fd = v′ evaluates to v0.fd = v′, and v.md(v′)evaluates to v0.md(v′).

The use of pcurrent(K)q |v captures two intuitive facts:(i) if the mode case value explicitly includes a case memberwhose label is the current mode of the enclosing sustainableblock, that case should be selected; (ii) otherwise, the casemember whose mode is greater to the current mode—butclosest to it—should be selected.

Recall that K at least contains `boot : m where m is thegreatest mode. This implies when a mode case value ap-pears outside of any sustainable block, the greatest mode isused. This aligns with our intution that code not subject tosustainability management should not be approximated.

The semantic definition here allows for nested first-classmode cases, with multiple R5 applications.

Sustainability Check.Several design possibilities exist as to when sustainablil-

ity check should happen, i.e., the timing for determiningwhether Match, Surplus, or Deficit holds: (1) check pe-riodically; (2) check whenever the supply gauge changes; (3)check whenever the demand gauge changes.

For route (1), we find it challenging and ad hoc to set afixed “period” that fits all programs: an interval of 100msmight be appropriate for a 15-second execution, but exceces-sive for a 15-minute execution. For (2), the supply gauge inenergy-aware programming is often associated with system-level variables (such as remaining battery) whose updatesare often performed outside the program runtime and outof the control of programmers. This may lead to platform-dependent behaviors: the same program may have sustain-ability checks at very different rates on two different laptops,just because they are equipped with different battery drivers.

Eco chooses route (3). According to our practice, the de-mand gauge is typically characterized with an expressionformed by program variables, such as loop index in the ex-ample in Figure 1. The state change of these variables isvisible and predictable to the programmer. It is our beliefthat for application-level energy management strategies—afamily that Eco belongs to—the programmer should havecontrol on program behaviors related to energy awareness.One conservative implementation of (3) would be to performsustainability check whenever state change happens, withthe following rules, where predicate InUBlock(K) holds iffthere exists ` ∈ K:

R6 : The evaluation of o.fd = v over heap H and contextK is a FJ-like field update over H if InUBlock(K).

R7 : The evaluation of o.fd = v over heap H and contextK is a FJ-like field update over H, together with theupdate of K to K0, (` : m′), given all of the followingconditions:

– ¬InUBlock(K)

– K = K0, (` : m)

– ` is a label for {e} J e1−> e′1 Ks J e2−> e′2 Kd– e1 evaluates to v1

– e′1 evaluates to v′1

– e2 evaluates to v2

– e′2 evaluates to v′2

– m′ = adjust(m, v1, v′1, v2, v

′2)

Rule R6 says that if the state change happens inside a uni-form block, no sustainability check is needed – the end goalof sustainability check is to adjust current mode, but uni-form blocks disallow adjustment. R7 says the state changeotherwise would lead to sustainability check – involving theevaluation of the supply sum/gauge expressions and the de-mand sum/gauge expressions – and ultimately the changeof the current mode for the enclosing sustainable block. Inpractice, R7 is prohibitively conservative: the change of o.fdmay have no effect on e′2 at all. We can optimize by intro-ducing:

R8 : The evaluation of o.fd = v over heap H and contextK is a FJ-like field update over H if

– K = K0, (` : m)

– ` is a label for {e} J e1−> e′1 Ks J e2−> e′2 Kd– ¬effect(o, e1, H), and ¬effect(o, e′1, H), and¬effect(o, e2, H), and ¬effect(o, e′2, H)

where predicate effect(o, e,H) says that changes in o mayaffect the evaluation of e. We leave this definition abstract;one possible implementation is that any subexpression of e(including e) does not alias to o. R8 is thus only appliedwhen the last condition described in the last bullet abovedoes not hold.

3.4 TypesType τ is either primitive num, or an object type X, or a

type for the mode case value mcase〈τ〉. The last type formsays that the expression defined for each case member hastype τ . A mode case definition is well-typed if the expres-sions for all case members have the same type τ , and we

1 int workdone = 0 ;2 int work l e f t = IMGS ∗ r e s . x ∗ r e s . y ;3 sustainable {4 for ( int num = 0 ; num < IMGS; num++) {5 . . .6 for ( int i = 0 ; i < IMAX; i++) {7 for ( int j = 0 ; j < JMAX; j++) {8 . . .9 }}

10 workdone+= IMAX ∗ JMAX;11 work l e f t = (IMGS−num) ∗ IMAX; JMAX;12 images [num] = image ;13 }14 }15 bsupply (PER ∗ BUDGET)16 demand ( workdone + work l e f t ) −> ( work l e f t ) ;

Figure 5: Refined Demand Characterization

type the mode case as mcase〈τ〉. Subtyping is defined as:(1) Java-style nominal subtyping still holds, in that if classX is a subclass of Y, then X is a subtype of Y. (2) mcase〈τ〉is a subtype of τ . A derived fact is that for a mode caseof type mcase〈τ〉, it is well-typed if any of its case memberexpression has type τ ′ as long as τ ′ is a subtype of τ .

The second rule above is friendly for incremental energy-aware support. A programmer can start with Java program-ming, and then incrementally change expressions such asnew Res(1024, 768) to the mode case we used in Figure 1.The rest of the source code remains unchanged, and the pro-gram still typechecks. This feature is particularly attractivefor upgrading legacy Java code such as libraries.

4. IMPLEMENTATION AND EVALUATIONEco is implemented on top of the Polyglot compiler frame-

work 3.0 [24], as an extension to Java. We selected the fol-lowing Java benchmarks and modified them into Eco: (1) sun-flow1, a rendering system that uses raytracing, (2) jspi-

der2, a web crawler, (3) montecarlo3, a financial simula-tion from the Java Grande benchmark suite, (4) xalan4, anXSLT processor that converts XML documents, and (5) ras-terizer, from the batik5 distribution, that rasterizes SVGfiles. Our main selection criterion is diversity, covering do-mains such as graphics, web, statistics, program transfor-mation, and data transformation. These benchmarks covera diverse range of applications to support variability in pro-gram behaviors, such as image resolution in sunflow, URLrequest intervals in jspider, sampling size in montecarlo,and rasterization quality in batik.

All experiments were performed on a Intel 2.53GHz Duocore CPU laptop with 8GB RAM. The battery data wasqueried through Advanced Configuration and Power Inter-face (ACPI) [1]. The system variable (in file form) be-ing queried is RemainingCapacity in BatteryStatus direc-tory, in milliwatt hours (mwh). The CPU temperature wasqueried with the CoreTemp6 tool. The tool queries temper-ature every 5 seconds, in Celsius.

4.1 Battery-Aware Programming (sunflow)1http://sunflow.sourceforge.net/2http://j-spider.sourceforge.net/3http://www.javagrande.org/4http://xalan.apache.org/5http://xmlgraphics.apache.org/batik/6http://www.alcpu.com/CoreTemp

0 10 20 30 40 50 60 70 80 90

100

1 101 201 301 401 501 601 701 801 901 1001 1101 1201 1301 1401 1501 1601 1701

%

Time(second)

normalized remaining supply normalized remaining demand

Figure 6: sunflow (PER = 0.9)

0 10 20 30 40 50 60 70 80 90

100

11 111 211 311 411 511 611 711 811 911 1011 1111 1211 1311

%

Time(second)

normalized remaining supply normalized remaining demand

Figure 7: sunflow (PER = 0.7)

0 10 20 30 40 50 60 70 80 90

100

1 101 201 301 401 501 601 701 801 901 1001

%

Time(second)

normalized remaining supply normalized remaining demand

Figure 8: sunflow (PER = 0.5)

PER supply set supply used # hi # mid # lo

0.9 18.86wh 18.60wh 5 4 00.7 14.70wh 14.21wh 1 7 10.5 10.48wh 10.33wh 1 2 6

Figure 9: sunflow: statistics

We modified the Java sunflow benchmark with Eco syn-tax. The rendering logic in sunflow resembles the examplein Figure 1. Our benchmarking execution renders 9 images(IMGS=9), and the resolution and depth are implemented asfirst-class mode case with identical definitions as in Figure 1.

The main difference between Figure 1 and our benchmarkis that we have refined the demand characterization, as inFigure 5. It not only considers the number of images asdemand indicators, but also the number of pixels in the im-ages. In the new scheme, the change of resolution wouldalter both the demand sum and demand gauge, because theadoption of a lower resolution in rendering an imagine re-duces both the work that has been completed (workdone),and our projection of the work ahead (workleft).

45

50

55

60

65

70

1 51 101 151 201 251 301 351 401 451 501 551 601 651

C

Time(second)

JAVA

ECO

Figure 10: xalan: CPU temperature

0 10 20 30 40 50 60 70 80 90

100

1 51 101 151 201 251 301 351 401 451 501 551 601 651

%

Time(second)

JAVA

ECO

Figure 11: xalan: CPU utilization

0

2

4

6

8

10

12

1 51 101 151 201 251 301 351 401 451 501 551 601 651

millisecond

Time(second)

Figure 12: xalan: sleep interval

We first execute the unmodified Java program and use itsbattery consumption as the baseline supply. This numberis used for setting the BUDGET constant in Figure 5. In ourexperiment, BUDGET = 20970mWh. We next execute the Ecoprogram with 90%, 70%, 50% of the BUDGET, with the timeseries of supply gauage (blue lines) and demand gauge (redlines) shown in Figure 6, Figure 7, Figure 8, respectively. Alldata are normalized. All experiments are started with thesame battery level. As one can see, battery supply change isnear linear. The change in demand happens at discrete time,depending on the updates of workdone and workleft in theprogram. Each “plateau” in the demand curve representsthe processing of one image. As high-resolution renderingtakes significantly longer time, the time series is also usefulin identifying mode changes.

Sustainability—the scenario where the supply consistentlymeets the demand—is maintained in all three scenarios: ob-serve the supply curve and the demand curve in all threefigures follow similar patterns of decline. Figure 9 reportsthe statistics of our experiments. Observe that in all cases,Eco runtime is capable of meeting the budget (i.e. the “sup-ply used” is less than the “supply set”). The #hi, #mid,#lo columns in the table list the number of images renderedwith high/mid/low resolutions. Predicably, more images arerendered with lower resolutions as the supply is set lower.

4.2 Temperature-Aware Programming (xalan)

0 10 20 30 40 50 60 70 80 90

100

1 101 201 301 401 501 601

%

Time(second)

supply(5.6wh) demand

Figure 13: batik: supply/demand (70% budget)

7000

8000

9000

10000

11000

12000

1 101 201 301 401 501 601

Image height (pixel)

Time(second)

Figure 14: batik: image height (70% budget)

We use xalan to transform 17 XML files with 8000 it-erations. We modify the original Java program as follows.First, we set a fixed temperature threshold to 60◦C. This isexpressed as tsupply(60 − temperature). Second, in be-tween every other file transformation, we allow the CPU tosleep at a fixed interval. A mode case is used for this sleepinterval, set with two case members: when the mode is hi,the interval is set at 4 milliseconds, whereas when the modeis lo, the interval is set at 10 milliseconds.

Figure 10 demonstrates the temperature changes of xalan,both in the Java execution and the Eco execution. xalan

is a CPU-intensive benchmark. Without any sustainabil-ity management, the Java execution drives the temperatureover 60◦C within one minute (a rise of about 15◦C). TheEco execution on the other hand successfully maintains theCPU temeperature within the threshold. Figure 11 mayexplain the fundamental difference between the two execu-tions, showing different levels of CPU activities (plotted withOS performance monitor). During the Java execution, theCPU utilization is mostly 100%. The Eco execution howeverregulates the CPU utilization at a much lower and dynamiclevel.

The figures here also demonstrates the trade-off betweentemperature regulation and performance. Without any sleep,the Java execution is able to complete the transformationwithin about half the time of the Eco execution. This comeswith no surpise: the latter execution intentionally slowsdown itself frequently. Figure 12 demonstrates the changeof sleep intervals over time.

4.3 Other benchmarksWe designed a battery-aware variant of batik, processing

27 SVG files with the supply of 8050mwh × 70%. Simi-lar to the fashion the sunflow experiment was constructed,8050mwh is the battery usage when we first executed the un-modified Java program, which we informally call “the bud-get.” The battery-aware variant thus runs on 70% of that

0 10 20 30 40 50 60 70 80 90

100

1 21 41 61 81 101 121 141 161

%

Time(second)

supply(1.6wh)

demand

Figure 15: montecarlo: supply/demand (80% bud-get)

0

50000

100000

150000

200000

250000

300000

1 21 41 61 81 101 121 141 161

data size

Time(second)

Figure 16: montecarlo: sample size (80% budget)

40

45

50

55

60

65

70

1 76 151 226 301 376 451 526 601 676 751

C

Time(second)

JAVA

ECO

Figure 17: jspider: temperature

0

10

20

30

40

50

60

70

80

90

100

1 76 151 226 301 376 451 526 601 676 751

%

Time(second)

JAVA

ECO

Figure 18: jspider: CPU utlization

0

500

1000

1500

2000

2500

1 76 151 226 301 376 451 526 601 676 751

Inte

rval

(mill

ise

con

d)

Time(second)

JAVA

ECO

Figure 19: jspider: sleep time

buget. The adaptive behaviors are defined by a mode casevalue for target image height. This value is strongly cor-related with the quality of rasterization. The mode case isdefined as {hi : 12000; mid : 10000; lo : 8000}, where 12000is used for the Java execution. As Figure 13 suggests, Eco

achieves the goal of sustainability by matching supply anddemand closely. Figure 14 shows the dynamic adaptive be-haviors when values of different case members are selected.

In montecarlo, a mode case is defined to adjust the sam-ple size. Specifically, the value in each case member is thedifference between the “perfect” sample size (280,000) andthe sample size being used for that mode. We use a synacticsugar to define this mode case (with a large number of caseswhose mode names are implicit), in the same effect of defin-ing {m0 : 0; . . . mi : i×∆; . . . mn : n×∆} where ∆ = 10, 000. Inother words, our benchmark adjusts the sample size by theincrement/decrement of ∆. The execution of the unmodi-fied Java code (for Monte Carlo core algorithm) consumes2060mwh of battery (“the budget”). The Eco execution op-erates on of 80% of that budget, with results shown in Fig-ure 15 and Figure 16. As Figure 15 suggests, Eco againmatches supply and demand closely. Figure 16 shows thechange of sample size over time.

We constructed a temperature-aware execution of jspi-

der in Eco. Similar to xalan, the temperature is also set atthe fixed threshold of 60◦C. We employ a similar strategy fortemperature control, by allowing the crawler to slep at fixedintervals. Unlike xalan where each XML file is processedin a relatively short period of time (less than 0.5 second),each step in crawling—involving requesting a URL, pars-ing the webpage, and analyzing the links contained in thepage—takes significantly longer. This allows us to designwith longer intervals of sleeps (but much less frequent thanxalan). The interval is implemented as a mode case, withhi mapping to 0.5 second, mid to 1 second, and hi to 2 sec-onds. Figure 17 shows the temperature results. Figure 17shows the CPU utilization, and Figure 19 shows the intervalchange. Typical for a web crawler, there is no “completion”time unless the user stops the execution. Our demand isset (and reset) at fixed time intervals. As a result, all timeseries shown here for jspider can be viewed as the first 800seconds of an (infinitely running) execution.

5. PROGRAMMING IDIOMSWe now summarize common programming idioms, many

of which we encountered while programming in Eco. Thesummary—by no means complete—may serve as a first steptoward understanding design patterns and micro-patternsof energy-aware software. Since our previous discussions aremore focused on demand characterization, the following dis-cussion focuses more on supply.

5.1 Fixed Supply CharacterizationVarious forms of fixed battery budget characterization can

be directly supported:

• fixed absolute battery budget, e.g., bsupply(20000) saysthe sustainable block execution can consume up to20000mwh of battery.

• fixed relative battery budget, e.g., bsupply(0.2∗battery)says the sustainable block execution can consume upto 20% of the remaining battery.

• maximum battery budget : clause bsupply(battery)says the sustainable block execution can as much asthe entire remaining battery.

Analogously, simple forms of temperature budget charac-terization are supported:

• fixed temperature threshold, e.g., the use of tsupply(70−temperature) says the sustainable block executionshould not increase the CPU temperature to more than70◦C.

• fixed temperature increase, e.g., tsupply(20) says thesustainable block execution should not increase theCPU temperature by more than 20◦C.

• fixed temperature increase ratio, e.g., tsupply(1.1 ∗temperature) says the sustainable block executionshould not increase the CPU temperature by morethan 10%.

5.2 Programming with Battery-Specific Sup-ply Units

The sugared syntax bsupply use battery capacity (mwh)as the unit of supply, and syntax tsupply uses temperaturein Celsius. These units are not hardcoded in Eco. More gen-erally, an Eco programmer may choose any unit intuitive andaccurate for her sustainability management, as long as suchvalues can be obtained from underlying OS and hardware.For example, popular battery-powered consumer computers(laptops and smartphones) typically come with power man-agement modules that can report the remaining operatingtime (or remaining percentage). A sustainable block thatshould consume no longer than 20% of the remaining oper-ating time can be programmed as:

1 sustainable {2 double startROT = 0.2 ∗ getROT ( ) ;3 . . .4 }5 supply ( startROT) ( startROT − getROT( ) )6 demand ( . . . ) ( . . . )

where getROT queries the system battery management mod-ule for the remaining operating time.

This example demonstrates an attractive trait of Eco: sus-tainable blocks are a high-level language abstraction inde-pendent of battery-specific units. From a language stand-point, what matters for a supply(e)(e′) specification is therelative proportion of the value represented by e′ within thatrepresented by e. Indeed, the suitable unit to report batteryState-of-Charge (SoC) [13] is dependent on many factors,such as (i) the characteristics of batteries, e.g. lithium-based or nickel-based; (ii) the support of OS, e.g. ACPI-compliant systems and different vendor extensions (such asPowerManager7 in Android); (iii) the estimation algorithms.The more user-friendly metrics—remaining percentage, orremaining operating time—are in fact derived metrics fromlower-level battery status data e.g. voltage level, currentlevel, and coulomb counts [13]. Under the backdrop of thisdiverse and fast-changing landscape, the abstraction pro-vided by Eco maintains a level of stability in the presence oftechnology changes: if next-generation programmers decidethe coulomb count is more precise for their energy-awaresoftware development, the programming model advocatedby Eco remains the same.

5.3 Programming with Custom Battery/Ther-mal Variations

Battery-powered computer users often observe that thesame level of demand that reduces battery from 80% to 78%

7http://developer.android.com

H ::= o 7→ 〈X;σ〉 heap

K ::= k contextk ::= ` : m | ` context elementσ ::= fd 7→ v field storev ::= n | o | {m : v} valuese ::= · · · | push k; e | pop; e extended expressionsE ::= ◦ evaluation context| {m : v, m : E, m : e}| E.fd | E.fd = e | v.fd = E| E.md(e) | v.md(E)| τ x = E; e

H{o, fd} def= σ(fd) where H(o) = 〈X;σ〉

H{o, fd→ v} def= H[o 7→ 〈X;σ[fd 7→ v]〉] if H(o) = 〈X;σ〉

H + {o, X} def= H ] (o 7→ 〈X;

]τ fd∈dom(fields(X))

fd 7→ null〉)

Figure 20: Eco Runtime Definitions

may reduces the same battery from 5% to 1%. Such non-linear battery behaviors are generally minimized by built-in OS/firmware estimators for new batteries, but they maybecome more pronouced as batteris age. If high precisionon battery supply is needed, such variations should not beignored and can be modeled in Eco as:

1 sustainable {2 double startB = 0.2∗ getB ( ) ;3 . . .4 }5 supply ( startB ) ( startB − r e d r e s s ( getB ( ) ) )6 demand ( . . . ) ( . . . )

where redress is a custom-defined function mapping read-ings from getBP to the “compensated” values. For example,one simplistic redress function would be to map value bto b if b ≥ 0.2 and b to 0.9 × b otherwise. As energy-awareprogramming becomes more prevalent, we envision such “re-dress” functions would be part of the “battery profile” avail-able to end programmers.

A similar programming idiom can be applied for non-linear thermal behaviors. According to solid matter physics,the energy to increase the temperature from 30◦C to 35◦Cand that from 300◦C to 305◦C significantly differ. The rangeof operating temperatures for CPUs is usually much nar-rower, so the non-linear effect makes little impact.

6. RELATED WORKModeling computer systems with supply and demand is

mostly known in operating system research. An incompletelist of examples include resource management and schedul-ing for grid environment [6], device energy management [31],utility computing in clouds [7], energy distribution amongusers [23]. Recently, the supply/demand model is also usedfor program runtime tuning [22]. Eco unleashes the power ofsupply and demand shaping to programmers in the contextof energy-aware programming.

Our prior work Energy Types [9] promoted mode-basedenergy management in programming. The focus of thatwork is a type system design—orthogonal to Eco—but Eco

(R-Cxt) H,K,E[e] ; H ′,K′,E[e′] if H,K, e ; H ′,K′, e′

(R-Push) H,K,push k; e ; H, (K, k), e(R-Pop) H, (K, k),pop; e ; H,K, e(R-Sustain) H,K, ` : {e} J e1−> e′1 Ks J e2−> e′2 Kd ; H,K,push (` : m); e; pop if m = current(K)(R-Uniform) H,K, ` : uniform {e} ; H,K,push `; e; pop(R-Mcase1) H,K, v.fd ; H,K, v′.fd if v′ = pcurrent(K)q |v(R-Mcase2) H,K, v.fd = v′′ ; H,K, v′.fd = v′′ if v′ = pcurrent(K)q |v(R-Mcase3) H,K, v.md(v′′) ; H,K, v′.md(v′′) if v′ = pcurrent(K)q |v(R-Write1) H,K, o.fd = v ; H{o, fd→ v},K, v if InUBlock(K)(R-Write2) H, (K, ` : m), o.fd = v ; H ′, (K, ` : m′), v if ¬InUBlock(K)

` : {e} J e1−> e′1 Ks J e2−> e′2 Kd in programH1 = H{o, fd→ v}H1,K, e1 ; H ′1,K, v1H ′1,K, e

′1 ; H ′2,K, v

′1

H ′2,K, e2 ; H ′3,K, v2H ′3,K, e

′2 ; H ′,K, v′2

m′ = adjust(m, v1, v′1, v2, v

′2)

(R-Read) H,K, o.fd ; H,K,H{o, fd}(R-Msg) H,K, o.md(v) ; H,K, e{v/x}{o/this} if H(o) = 〈X;σ〉

mbody(md, X) = x.e(R-New) H,K,new X ; H + {o, X},K, o if o fresh

Figure 21: Eco Operational Semantics

inherits the concept of modes from there. EnerJ [27] is an-other programming model where program data can be la-beled as either “precise” or “approximated,” a special form ofmodes. Neither Energy Types nor EnerJ supports first-classmode cases, nor do they support sustainable programming.Green [4] defines a program approximation framework thatguarantees programmer-specified QoS, and performs loop/-function approximations to save energy. Green focuses onQoS guarantees. It neither supports programmer-specifiedenergy budget, nor program sustainability.

Eon [30] is a domain-specific language for sensor networks.Built upon a data-flow model, Eon runtime may adjust dataflow paths based on the status of solar production and bat-tery utilization. Eon supports a (hardcoded) form of sus-tainability: the runtime balances solar and battery, so thatthe program can run “perpetually.” Eco not only providesa sustainable program runtime, but also a sustainable pro-gramming model, where supply and demand are character-ized by program elements.

Energy-aware software is an active research area in soft-ware engineering, with diverse efforts on program analysis(e.g. [5, 15]), cost estimation (e.g. [28]), debugging (e.g. [2]),software architectures (e.g. [19]), design patterns (e.g.[21,26]), and compiler optimizations (e.g. [16]).

There is a long history in VLSI, architecture, and OS com-munities to design battery-aware (e.g. [11]) or temperature-aware (e.g. [29]) computer systems. A fundamental chal-lenge is the need to“predict the future,” with solutions rang-ing from profiling and monitoring [10], machine learning [8],to agent-based modeling [12]. Eco complements existing sys-tems by bringing programmer knowledge into the designspace. The approaches are not exclusive, and in the longrun, we believe hybrid approaches may further improve theeffectiveness.

7. CONCLUSIONThis paper describes Eco, the first programming language

of its kind to support sustainable programming in Java-like languages. With novel abstractions for supply and de-mand shaping, Eco brings programmers into the loop ofsustainability management. With a surprisingly compactand simple model, Eco promotes battery-aware program-ming and temperature-aware programming, and more gen-erally, energy-aware software development.

This work is supported by NSF CAREER Award CCF-1054515 and a REU supplement.

APPENDIXA. OPERATIONAL SEMANTICS

Figure 20 defines the runtime structures, including heapH, context K, and extended expressions e with push andpop operators. Furthermore, all sustainable blocks and uni-form blocks are associated with unique program labels `.Evaluation context E is useful for defining evaluation order,defined either as a hole ◦, or an expression with a hole in-side. Notation E[e] means replacing the whole in E withexpression e. Given sequence S = [a1 7→ b1, . . . an 7→ bn],

we define dom(S)def= {a1, . . . , an}. Given two sequences S1

and S2, S1 ] S2def= S1, S2 if dom(S1) ∩ dom(S2) = ∅; it is

undefined otherwise.Figure 21 defines the operational semantics of Eco, where

notation H,K, e ; H ′,K′, e′ means e evaluates to e′ whereheap H updates to H ′ and context K updates to K′. FJfunction mbody(md, X) computes the method body of methodmd of an object of class X, in the form of x.e where x isthe formal argument. FJ function fields(X) computes thesequence of field definitions of class X. Notation e{v/x} com-putes an expression identical to e, except every occurrenceof x is substituted with v.

B. REFERENCES[1] Advanced configuration and power interface,

http://www.acpi.info.

[2] Carat, http://carat.cs.berkeley.edu.

[3] Data centers look for lower-emission cooling,http://www.nytimes.com/2011/06/20/business/

global/20green.html.

[4] Baek, W., and Chilimbi, T. M. Green: a frameworkfor supporting energy-conscious programming usingcontrolled approximation. In PLDI’10 (2010),pp. 198–209.

[5] Bartenstein, T., and Liu, Y. D. Green streams fordata-intensive software. In ICSE’13 (May 2013).

[6] Buyya, R., Abramson, D., Giddy, J., andStockinger, H. Economic models for resourcemanagement and scheduling in grid computing.Concurrency and computation: practice andexperience 14, 13-15 (2002), 1507–1542.

[7] Buyya, R., Yeo, C. S., and Venugopal, S.Market-oriented cloud computing: Vision, hype, andreality for delivering it services as computing utilities.In Proceedings of the 2008 10th IEEE InternationalConference on High Performance Computing andCommunications (2008), HPCC ’08, pp. 5–13.

[8] Chung, E.-Y., Benini, L., and De Micheli, G.Dynamic power management using adaptive learningtree. In Proceedings of the 1999 IEEE/ACMinternational conference on Computer-aided design(1999), ICCAD ’99, pp. 274–279.

[9] Cohen, M., Zhu, H. S., Emgin, S. E., and Liu,Y. D. Energy types. In OOPSLA ’12 (October 2012).

[10] Contreras, G., and Martonosi, M. Powerprediction for Intel XScale processors usingperformance monitoring unit events. In Proceedings ofthe 2005 international symposium on Low powerelectronics and design (2005), ISLPED ’05,pp. 221–226.

[11] Flinn, J., and Satyanarayanan, M. Managingbattery lifetime with energy-aware adaptation. ACMTrans. Comput. Syst. 22, 2 (May 2004), 137–179.

[12] Ge, Y., Qiu, Q., and Wu, Q. A multi-agentframework for thermal aware task migration inmany-core systems. IEEE Trans. Very Large ScaleIntegr. Syst. 20, 10 (Oct. 2012), 1758–1771.

[13] Glover, J. D. D., and Sarma, M. S. Power SystemAnalysis and Design, 3rd ed. Brooks/Cole PublishingCo., Pacific Grove, CA, USA, 2001.

[14] Gray, J. The transaction concept: virtues andlimitations (invited paper). In Proceedings of theseventh international conference on Very Large DataBases - Volume 7 (1981), VLDB ’81, pp. 144–154.

[15] Hao, S., Li, D., Halfond, W. G. J., andGovindan, R. Estimating mobile application energyconsumption using program analysis. In ICSE ’13(2013), pp. 92–101.

[16] Hsu, C.-H., and Kremer, U. The design,implementation, and evaluation of a compileralgorithm for cpu energy reduction. In PLDI’03(2003), pp. 38–48.

[17] Igarashi, A., Pierce, B., and Wadler, P.Featherweight java - a minimal core calculus for javaand gj. In ACM Transactions on Programming

Languages and Systems (1999), pp. 132–146.

[18] Kulkarni, A., Liu, Y. D., and Smith, S. F. Tasktypes for pervasive atomicity. In OOPSLA’10(October 2010).

[19] Lago, P., Jansen, T., and Jansen, M. The servicegreenery-integrating sustainability in service orientedsoftware. In International Workshop on SoftwareResearch and Climate Change (WSRCC), co-locatedwith ICSE (2010), vol. 2.

[20] Liskov, B. Distributed programming in argus.Commun. ACM 31, 3 (1988), 300–312.

[21] Liu, Y. D. Energy-efficient synchronization throughprogram patterns. In First International Workshop onGreen and Sustainable Software, (GREENS 2012)(2012), pp. 35–40.

[22] Mitchell, N., and Sweeney, P. F. On the flycapacity planning. In OOPSLA ’13 (October 2013).

[23] Narasimhan, S., McIntyre, D. R., Wolff, F. G.,Zhou, Y., Weyer, D. J., and Bhunia, S. Asupply-demand model based scalable energymanagement system for improved energy utilizationefficiency. In International Conference on GreenComputing (2010), IEEE, pp. 97–105.

[24] Nystrom, N., Clarkson, M. R., and Myers,A. C. Polyglot: An extensible compiler framework forjava. In International Conference on CompilerConstruction (Apr. 2003), pp. 138–152.

[25] Pering, T., Burd, T., and Brodersen, R. Thesimulation and evaluation of dynamic voltage scalingalgorithms. In Proceedings of the 1998 internationalsymposium on Low power electronics and design(ISLPED) (1998), pp. 76–81.

[26] Sahin, C., Cayci, F., Gutierrez, I. L. M., Clause,J., Kiamilev, F. E., Pollock, L. L., andWinbladh, K. Initial explorations on design patternenergy usage. In First International Workshop onGreen and Sustainable Software, (GREENS 2012)(2012), pp. 55–61.

[27] Sampson, A., Dietl, W., Fortuna, E.,Gnanapragasam, D., Ceze, L., and Grossman, D.EnerJ: Approximate data types for safe and generallow-power computation. In PLDI’11 (June 2011).

[28] Seo, C., Malek, S., and Medvidovic, N. Anenergy consumption framework for distributedjava-based systems. In ASE ’07 (2007), pp. 421–424.

[29] Skadron, K., Stan, M. R., Huang, W., Velusamy,S., Sankaranarayanan, K., and Tarjan, D.Temperature-aware microarchitecture. In Proceedingsof the 30th annual international symposium onComputer architecture (2003), ISCA ’03, pp. 2–13.

[30] Sorber, J., Kostadinov, A., Garber, M.,Brennan, M., Corner, M. D., and Berger, E. D.Eon: a language and runtime system for perpetualsystems. In SenSys ’07: Proceedings of the 5thinternational conference on Embedded networkedsensor systems (2007), pp. 161–174.

[31] Zeng, H., Ellis, C. S., Lebeck, A. R., andVahdat, A. Ecosystem: managing energy as a firstclass operating system resource. In Proceedings of the10th international conference on Architectural supportfor programming languages and operating systems(2002), ASPLOS X, pp. 123–132.