=Paper=
{{Paper
|id=Vol-2286/paper_3
|storemode=property
|title=Characterizing a source code model with energy measurements
|pdfUrl=https://ceur-ws.org/Vol-2286/paper_3.pdf
|volume=Vol-2286
|authors=Thibault Béziers La Fosse,Jean-Marie Mottu,Massimo Tisi,Jérôme Rocheteau,Gerson Sunyé
|dblpUrl=https://dblp.org/rec/conf/esem/FosseMTRS18
}}
==Characterizing a source code model with energy measurements==
https://ceur-ws.org/Vol-2286/paper_3.pdf
1
Characterizing a Source Code Model with Energy
Measurements
Thibault Béziers la Fosse, Jean-Marie Mottu, Massimo Tisi, Jérôme Rocheteau and Gerson Sunyé
ICAM, IMT Atlantique, LS2N
Nantes
Email: first-name.last-name@ls2n.fr
Abstract—Energy consumption is a critical point when de- its syntax and semantic [9]. Such model is typically used
veloping applications. Either for battery-saving purposes, for during the software development, as a specification model to
lowering the cost of data-centers, or simply for the sake of generate a source code, or as a source code model, reverse-
having an eco-friendly program, reducing the energy needed to
run a software becomes mandatory. Model-Driven Engineering engineered from the software in order to analyze or refactor
has shown great results when it comes to program understanding it.
and refactoring. Modeling the source code along with its energy This paper proposes a MDE approach for modeling the
consumption could be a powerful asset to programmers in order source code of a software and characterizing it with energy
to develop greener code. For that purpose, this paper presents an
measurements. A first model of this software is generated
approach for modeling energy consumption inside a source code
model. Energy metrics are gathered at runtime, modeled using with the static reverse-engineering framework MoDisco [10].
the standard Structured Metrics Meta-model, and associated to In addition we propose a framework dynamically gathering
the source code model, enabling model-driven techniques for energy measurements, at runtime.
energy analysis and optimizations. Those measurements are persisted in a second model con-
forming to the Structured Metrics Meta-model1 (SMM). In
I. I NTRODUCTION order to characterize the source code with energy metrics, the
Energy Consumption becomes a major concern when devel- two models are associated: elements in the source code (e.g.,
oping software. The massive electricity needs of data-centers Java methods) are linked to the energy measurements, enabling
represented 1.8% total U.S. consumption in 2016, and an the analysis of the source code energy consumption.
estimated account for about 2% of global greenhouse gas [1]– This paper is organized as follows: Section II presents
[3]. Furthermore, the expense to power and cool the data- related work, Section III presents our approach, Section IV
centers escalated to a significant cost factor: for every $1.00 discusses the approach, Section V presents the threats to the
spent on new hardware, an additional $0.50 is spent on power validity of our approach, and Section VI concludes the paper.
and cooling [4]. Those factors severely limits the expansion of
IT resources. Reducing the consumption of software systems
II. R ELATED W ORK
has thus become an important ecological, economical, and
technological challenge. A large amount of research has been done around software-
Traditionally, such concerns tend to be addressed at the level energy monitoring, optimization, and management, re-
lower levels (hardware or middleware), and several strategies sulting in the production of several well-known tools. For
have been presented in the past years towards that pur- instance in the realm of software-based energy measurements,
pose [5]. However, promising results have been introduced us- J RAPL [6] is a Java API for profiling Java programs running
ing software-level energy management approaches [6], which, on CPUs supporting Intel’s Running Average Power Limit
combined with lower level optimizations, can effectively re- (RAPL). It can be used through a single line of Java code, and
duce the energy consumption of programs. provides the energy consumed by the CPU cores. However,
Unlike hardware-level energy saving techniques, software- the energy it measures includes the energy consumed by the
level approaches often need the implication of developers. In system, and induces a considerable overhead [11], threatening
fact, to develop a greener code, a certain level of energy- the validity of the measurements.
awareness is helpful to make relevant design choices. A The following applications also perform at the software
study showed that more than 80% of programmers did not level. B IT WATTS is a middleware extension of the P OWER API
consider the energy consumption when developing softwares, toolkit, able to monitor the power consumption at the process-
even if they know how important it can be, especially in the level in VM-based systems [12], [13]. It collects process us-
realm of mobile application development [7], [8]. We believe ages and estimates a fine-grained power consumption based on
that a representation of a source code, along with energy a power model. JALEN uses statistical sampling for estimating
consumption would help developers making the right design the energy consumption of software code [14]. Relying on
choices. P OWER API too, it isolates selected classes and methods and
In the realm of Model-Driven Engineering (MDE), this rep-
resentation is a model, conforming to a meta-model describing 1 https://www.omg.org/spec/SMM/
2
monitors them through Java agents. P T OP proposes a process- 1 p a c k a g e m a i n P a c k a g e ;
level profiling tool, running at the kernel level and monitoring 2
the energy consumptions of all the application of the system, 3 p u b l i c c l a s s App {
4
at a small cost, and with no performance side effects on the 5 p u b l i c s t a t i c v o i d main ( S t r i n g [ ] a r g s ) {
running applications. P T OP, B IT WATTS and JALEN measure 6 foo ( ) ;
powers at a fixed frequency, making challenging the energy 7 }
8
measurement of short-running programs. Nonetheless they 9 p u b l i c s t a t i c void foo ( ) {
rely on power models and are not impacted by the system 10 / / do s o m e t h i n g
consumption. On the contrary, J RAPL can be queried at any 11 }
12
time (e.g. comparing the energy consumed before and after 13 }
running a portion of code, in order to provide the energy it 14
consumed), but gives raw energy consumptions, includes the
system’s one, and has a major impact on the accuracy of the Figure 1. Simple Java program
measurements.
Those approaches estimate power and energy consumption :Package
using energy models based on system specifications and usage.
name = mainPackage
However they do not make the measurements available for
Model-Driven analysis tools. Our approach does not aim at
:ClassDeclaration
improving the precision w.r.t. related work, but representing it
name = App
in an holistic model, enabling further model-driven analysis.
III. A PPROACH :MethodDeclaration :MethodDeclaration
name = main name = foo
We detail in this section the several steps necessary to
characterize our source code model with energy measure-
Figure 2. Excerpt of the MoDisco source code model
ments. First, the source code model is statically built using the
MoDisco reverse-engineering framework. Second, the code is
instrumented, in order to add probes inside the program, which instrumentation library3 for that purpose. The JVM byte-code
is then executed to gather the energy measurements at runtime. is visited, and probes are added in the byte-code of every
Third, the measurements are persisted in a model conforming method of the program. A first probe is added in every method
to the Structured Metrics Meta-model, and associated with the entry point, traces down the method call, gets the system
MoDisco source code model. The Java program in Figure 1 time, and finally gets the energy consumed by the CPU at
is used to describe our approach. Our application is available the specific moment, in microjoule.
on GitHub2 . Another probe is added at every method exit point. This
second probe computes the duration of this method execution,
A. Source Code Model and the energy it has consumed. To do so, the energy con-
sumed by the CPU is fetched a second time, and subtracted to
The MoDisco framework [10] is designed to enable program
the value obtained in the first probe. Our energy measurements
analysis, by creating a static model of a source code using
are performed using the same approach as jRAPL [6].
reverse-engineering. Considering a source code written in Java,
MoDisco generates the corresponding model conforming to a As an example, considering the Java source-code available
Java meta-model. This model only represents static aspects of in Figure 1, the byte-code generated, and its instrumented
the code, such as classes, methods, statements or expressions. version would be the ones in Figure 3 and Figure 4. Figure 3
The energy measurements have to be dynamically gathered, contains the byte-code of the main as method described in
and are not available in the initial MoDisco model. Nonethe- Figure 1. This byte-code simply embeds a static invocation of
less, a benefit of MDE is that such measurements can be the foo method. Figure 4 also embeds this static invocation of
modeled and then associated with our source code model, the foo method, however, probes have been added at the entry
as presented in the next sections. Applying MoDisco on the and exit points of the method. The probe located at the entry
program in Figure 1 would produce a model containing all point of the method is called by instantiating a class named
the source-code elements of such program. An excerpt of this Probe. The constructor of this class takes as a parameter the
model is available in Figure 2. qualified name of the method it located in, and computes the
energy consumed before the execution. Once the exit point of
the method is reached, the exit method of the probe is called.
B. Energy Measurements Computation This method gets the energy consumed, compares it with the
Once the source code model is generated, the energy is value obtained at the entry point, and traces that value.
measured. In order to get such measurements for each method Note that if a second method is called inside a first method,
in the program, it has to be instrumented. We use the ASM then the energy consumed by this first method includes the
2 https://github.com/atlanmod/EnergyModel 3 https://asm.ow2.io/
3
1 p u b l i c s t a t i c v o i d main ( j a v a . l a n g . S t r i n g [ ] ) ;
2 d e s c r i p t o r : ( [ Ljava / lang / S t r i n g ; )V
3 f l a g s : ACC PUBLIC , ACC STATIC
4 Code :
5 s t a c k =3 , l o c a l s =2 , a r g s s i z e =1
6
7 0 : new #11 / / c l a s s Probe
8 3 : dup
1 p u b l i c s t a t i c v o i d main ( j a v a . l a n g . S t r i n g [ ] ) ; 9 4: ldc #25 / / S t r i n g m a i n P a c k a g e . App$main
2 d e s c r i p t o r : ( [ Ljava / lang / S t r i n g ; )V 10 6 : i n v o k e s p e c i a l #16 / / Method P r o b e .” < i n i t > ” : [ . . . ]
3 f l a g s : ACC PUBLIC , ACC STATIC 11 9: astore 1
4 Code : 12 1 0 : i n v o k e s t a t i c #28 / / Method f o o : ( ) V
5 s t a c k =0 , l o c a l s =1 , a r g s s i z e =1 13 13: aload 1
6 14 14: ldc #25 / / S t r i n g App$main
7 0: invokestatic #2 / / Method f o o : ( ) V 15 1 6 : i n v o k e v i r t u a l #19 / / Method P r o b e . e x i t : [ . . . ]
8 3: return 16 19: r e t u r n
Figure 3. Non-instrumented byte-code of the main method Figure 4. Instrumented byte-code of the main method
energy consumed by the second one. For instance, if we Furthermore, the timestamps of the methods invocations are
consider the code in Figure 1, the energy consumed by the available in the ObservedMeasure elements. Finally the
main() method will include the energy consumed by the source code model elements (e.g. MethodDeclaration)
foo() method. Hence it could be possible to approximate the are associated to the Measurement using the link labeled
energy consumed only by main() by subtracting the energy as measurand.
foo() consumed, thanks to the available energy model.
Running the instrumented code triggers the probes to gather IV. D ISCUSSION
measurements. For each method, the following metrics are
obtained: This source code model characterized with energy mea-
surements offers developers a better energy-awareness than
1) Its timestamp
standard software engineering techniques: First, an holistic
2) The energy it consumed
model of the program is created. The association between
3) The methods that have been called inside.
MoDisco’s Java meta-model and SMM offers a representation
Running the code can be done either by executing the of the source code characterized with several dynamic infor-
main method of a program, or through test cases. During the mation, available for analysis purposes. Second, the program
execution, the measurements are published on a messaging can be refactored and optimized only by working at the model
queue, in order to be analyzed after the execution. Indeed, level.
analyzing the traces is an expensive operation, and performing
Programmers can specify transformation rules for refac-
it after the execution limits the overhead induced by the
toring [16], without having to go back to the source code
execution of the instrumented statements.
level, in order to optimize the energy consumption using
Furthermore, our approach is relying on existing energy
existing energy-efficient practices [17]–[20]. As stated by G.
measurement tools, and do not aim at improving their accu-
Pinto et al., refactoring approaches focusing on improving
racy. Performing the measures causes an important workload,
the energy consumption of programs are lacking [21]. Our
limiting the accuracy of the energy measurements [15]. For
model could help programmers refactoring their applications
that reason, we can only provide the energy consumed at the
towards that purpose, by specifying a model transformation to
method level, or at coarser granularities.
apply to the source-code model, and generating the program
optimized [22]. The energy measurements present in the model
C. Energy Measurements Modeling can be used as predicates for the transformation. For instance,
In this main step of our approach, we persist the energy a model transformation could be specified, only targeting
measurements into a model conforming to SMM and associate the methods that consume more than a specified energy.
it to the source code model that MoDisco generates. This is This transformation would change all the existing Doubles to
performed by reading the measurements sent in the messaging Floats, as it has been shown that it can reduce the energy
queue one by one. Energy consumed, timestamps and internal consumption [6]. The modified source code of the program
method calls are persisted as elements in the model. Finally can then be generated again, using MoDisco code generator,
the measurements are linked to the methods from the source- and be used to consume less energy.
code level, hence characterizing those. Furthermore, our model can easily be used by external
In Figure 5, the energy consumed is contained in the model-driven tools. The fact that this model is persisted with
Measurement elements, as values. The method calls are the Eclipse Modeling Framework’s XMI standard enables an
represented using the MeasurementRelationship. The important re-usability, especially within the Eclipse environ-
”before” and ”after” links point towards the Measurement ment [23]. As an example, the Sirius Framework is built on top
elements, describing in which order the methods have been of the Graphical Modeling Framework (GMF), and enables the
called. Here for instance, main() calls foo(). editing, manipulation and creation of models through custom
4
:SmmModel
:Package
name = mainPackage
:Observation
:ClassDeclaration
:ObservedMeasure :ObservedMeasure name = App
timeStamp = 1532337412 timeStamp = 1532337415
:Measurement :Measurement :Measurement
before after :MethodDeclaration :MethodDeclaration
Relationship
name = main EC (μJ) name = foo EC (μJ)
name = foo name = main
value = 2825 name = "order" value = 2821
measurand measurand
Figure 5. Excerpt of the source code model (the MethodDeclaration instances) characterized with energy measurements
been quantified here, and which threatens the accuracy of the
measurements. Furthermore, RAPL also includes the energy
that the exploitation system is consuming. For that reason, the
energy measurements we are able to gather with our current
tooling might not be accurate. Finer energy estimations will
be done later over this model.
Furthermore, MDE suffers from some well-known scalabil-
ity issues. Our model is persisted using the XMI standard,
however, as explained by Javier Espinazo-Pagán et al., XMI
files cannot be partially loaded [25]. For that reason the XMI
persistence layer tends to scale badly when the models are too
large: in order to be used, the entire model have to fit entirely
in memory. We encountered this issue when generating the
MoDisco model of Java projects having more than 10,000
Figure 6. A graphical representation of the Energy model inside Sirius classes. This well-known scalability issue can be resolved
using scalable persistence layers for EMF models, such as
CDO4 or NeoEMF [26]. Our current prototype does not rely
graphical interfaces [24]. In order to help developers locating on those scalable persistence layers yet.
energy consuming method, we used Sirius to build a simple
graphical representation of the source code, highlighting the VI. C ONCLUSION AND F UTURE W ORK
methods that consume more than a specified threshold. A
This paper presents an approach for modeling the source
screen-shot of such application is available in Section IV.
code of an application and decorating it with energy mea-
This figure shows the energy consumed by the main and foo
surements. Those measurements are dynamically gathered,
methods, as presented in Figure 5, and the energy consumed
modeled using SMM, and associated with a source code
by a test case launching the main method. An energy limit
model statically generated by MoDisco. This model can be
has been set to 2822µJ, hence highlighting all the methods
used by programmers as a basis for analyzing and optimizing
consuming more than that threshold. This example shows
programs, and offers a better energy-awareness, useful for
that this model can be used in order to provide developers
implementing greener applications.
feedbacks about the energy consumption of their programs,
In our future work, we plan to refine the energy mea-
and hence help them doing the right design choices, and
surements gathered in our approach. In fact, measuring the
improving their energy awareness.
energy consumed by the program using RAPL induces an
overhead and includes the entire system energy consumption.
V. T HREAT TO VALIDITY Furthermore, instead of using XMI for persisting our models,
a more scalable persistence layer, such as NeoEMF, will be
Several points have to be considered, in regard to the
used.
validity of our approach. First of all, our current model
does not aim at containing the precise energy consumption
R EFERENCES
measurement for each method. It stores in a standard model
the information we gather from our measuring tools. In our im- [1] G. Cook, “How clean is your cloud,” Catalysing an energy revolution,
p. 11, 2012.
plementation we used RAPL to measure the energy consumed
by the program. RAPL induces an overhead, that has not 4 https://www.eclipse.org/cdo/
5
[2] M. Webb et al., “Smart 2020: Enabling the low carbon economy in the for very large models,” Science of Computer Programming, vol. 149,
information age,” The Climate Group. London, vol. 1, no. 1, pp. 1–1, pp. 9–14, 2017.
2008.
[3] A. Shehabi, S. Smith, D. Sartor, R. Brown, M. Herrlin, J. Koomey,
E. Masanet, N. Horner, I. Azevedo, and W. Lintner, “United states data
center energy usage report,” 2016.
[4] M. J. Scaramella and M. Eastwood, “Solutions for the datacenter’s
thermal challenges,” IDC, January, 2007.
[5] S. Mittal, “A survey of techniques for improving energy efficiency
in embedded computing systems,” International Journal of Computer
Aided Engineering and Technology, vol. 6, no. 4, pp. 440–459, 2014.
[6] K. Liu, G. Pinto, and Y. D. Liu, “Data-oriented characterization
of application-level energy optimization,” in International Conference
FASE’15. Springer.
[7] I. Manotas, L. Pollock, and J. Clause, “Seeds: a software engineer’s
energy-optimization decision support framework,” in Proceedings of the
36th International Conference on Software Engineering. ACM, 2014,
pp. 503–514.
[8] C. Pang, A. Hindle, B. Adams, and A. E. Hassan, “What do pro-
grammers know about software energy consumption?” IEEE Software,
vol. 33, no. 3, pp. 83–89, 2016.
[9] J. Bézivin, “On the unification power of models,” Software & Systems
Modeling, vol. 4, no. 2, pp. 171–188, 2005.
[10] H. Bruneliere, J. Cabot, F. Jouault, and F. Madiot, “Modisco: a generic
and extensible framework for model driven reverse engineering,” in
Proceedings of the IEEE/ACM International Conference ASE’10. ACM.
[11] H. Zhang and H. Hoffman, “A quantitative evaluation of the rapl power
control system,” Feedback Computing, 2015.
[12] A. Bourdon, A. Noureddine, R. Rouvoy, and L. Seinturier, “Powerapi:
A software library to monitor the energy consumed at the process-level,”
ERCIM News, vol. 2013, no. 92, 2013.
[13] M. Colmant, M. Kurpicz, P. Felber, L. Huertas, R. Rouvoy, and A. Sobe,
“Process-level power estimation in vm-based systems,” in Proceedings
of EuroSys’15. ACM.
[14] A. Noureddine, R. Rouvoy, and L. Seinturier, “Unit testing of energy
consumption of software libraries,” in Proceedings of the 29th Annual
ACM Symposium on Applied Computing. ACM, 2014, pp. 1200–1205.
[15] S. a. Rivoire, M. A. Shah, P. Ranganathan, and C. Kozyrakis, “Joulesort:
a balanced energy-efficiency benchmark,” in Proceedings of the 2007
ACM SIGMOD international conference on Management of data. ACM,
2007, pp. 365–376.
[16] M. Fowler, K. Beck, J. Brant, W. Opdyke, and D. Roberts, Refactoring:
improving the design of existing code. Addison-Wesley Professional,
1999.
[17] R. Pereira, M. Couto, J. Saraiva, J. Cunha, and J. P. Fernandes,
“The influence of the java collection framework on overall energy
consumption,” in GREENS’16. ACM, 2016.
[18] G. Procaccianti, H. Fernández, and P. Lago, “Empirical evaluation of
two best practices for energy-efficient software development,” Journal
of Systems and Software, vol. 117, pp. 185–198, 2016.
[19] A. Sampson, W. Dietl, E. Fortuna, D. Gnanapragasam, L. Ceze, and
D. Grossman, “Enerj: Approximate data types for safe and general low-
power computation,” in ACM SIGPLAN Notices, vol. 46, no. 6. ACM,
2011, pp. 164–174.
[20] W. G. da Silva, L. Brisolara, U. B. Correa, and L. Carro, “Evaluation
of the impact of code refactoring on embedded software efficiency,” in
Proceedings of the 1st Workshop de Sistemas Embarcados, 2010, pp.
145–150.
[21] G. Pinto, F. Soares-Neto, and F. Castor, “Refactoring for energy effi-
ciency: a reflection on the state of the art,” in Proceedings of the Fourth
International Workshop on Green and Sustainable Software. IEEE
Press, 2015, pp. 29–35.
[22] F. Jouault, F. Allilaire, J. Bézivin, and I. Kurtev, “Atl: A model
transformation tool,” Science of computer programming, vol. 72, no.
1-2, pp. 31–39, 2008.
[23] D. Steinberg, F. Budinsky, E. Merks, and M. Paternostro, EMF: eclipse
modeling framework. Pearson Education, 2008.
[24] V. Viyović, M. Maksimović, and B. Perisić, “Sirius: A rapid development
of dsm graphical editor,” in Intelligent Engineering Systems (INES),
2014 18th International Conference on. IEEE, 2014, pp. 233–238.
[25] J. E. Pagán, J. S. Cuadrado, and J. G. Molina, “Morsa: A scalable
approach for persisting and accessing large models,” in International
Conference on Model Driven Engineering Languages and Systems.
Springer, 2011, pp. 77–92.
[26] G. Daniel, G. Sunyé, A. Benelallam, M. Tisi, Y. Vernageau, A. Gómez,
and J. Cabot, “Neoemf: a multi-database model persistence framework