Fernando Castor

Mining questions about software energy consumption

A growing number of software solutions have been proposed to address application-level energy consumption problems in the last few years. However, little is known about how much software developers are concerned about energy consumption, what aspects of energy consumption they consider important, and what solutions they have in mind for improving energy efficiency. In this paper we present the first empirical study on understanding the views of application programmers on software energy consumption problems. Using StackOverflow as our primary data source, we analyze a carefully curated sample of more than 300 questions and 550 answers from more than 800 users. With this data, we observed a number of interesting findings. Our study shows that practitioners are aware of the energy consumption problems: the questions they ask are not only diverse -- we found 5 main themes of questions -- but also often more interesting and challenging when compared to the control question set. Even though energy consumption-related questions are popular when considering a number of different popularity measures, the same cannot be said about the quality of their answers. In addition, we observed that some of these answers are often flawed or vague. We contrast the advice provided by these answers with the state-of-the-art research on energy consumption. Our summary of software energy consumption problems may help researchers focus on what matters the most to software developers and end users.

A large-scale study on the usage of Java's concurrent programming constructs

An analysis of 2227 Java projects, comprising more than 650 million lines of code.Seventy seven percent of the projects create threads or employ a concurrency control mechanism.Concurrent programming constructs are used both frequently and intensively.Adoption of java.util.concurrent is moderate (23% of the concurrent projects use it).Efficient and safe data structures, e.g., ConcurrentHashMap, are not yet widely used. In both academia and industry, there is a strong belief that multicore technology will radically change the way software is built. However, little is known about the current state of use of concurrent programming constructs. In this work we present an empirical work aimed at studying the usage of concurrent programming constructs of 2227 real world, stable and mature Java projects from SourceForge. We have studied the usage of concurrent techniques in the most recent versions of these applications and also how usage has evolved along time. The main findings of our study are: (I) More than 75% of the latest versions of the projects either explicitly create threads or employ some concurrency control mechanism. (II) More than half of these projects exhibit at least 47 synchronized methods and 3 implementations of the Runnable interface per 100,000 LoC, which means that not only concurrent programming constructs are used often but they are also employed intensively. (III) The adoption of the java.util.concurrent library is only moderate (approximately 23% of the concurrent projects employ it). (IV) Efficient and thread-safe data structures, such as ConcurrentHashMap, are not yet widely used, despite the fact that they present numerous advantages.

Are Java programmers transitioning to multicore?: a large scale study of java FLOSS

We would like to know if Java developers are retrofitting applications to become concurrent and, to get better performance on multicore machines. Also, we would like to know what concurrent programming constructs they currently use. Evidence of how programmers write concurrent programs can help other programmers to be more efficient when using the available constructs. Moreover, this evidence can assist researchers in devising new mechanisms and improving existing ones. For this purpose, we have conducted a study targeting a large-scale Java open source repository, SourceForge. We have analyzed a number of FLOSS projects along two dimensions: spatial and temporal. For the spatial dimension, we studied the latest versions of more than 2000 projects. Our goal is to understand which constructs developers of concurrent systems employ and how frequently they use them. For the temporal dimension we took a closer look at various versions of six projects and analyzed how the use of concurrency constructs has evolved over time. In addition, we tried to establish if uses of concurrency control constructs were aimed at leveraging multicore processors. We have downloaded more than two thousand Java projects including their various versions, in addition to individual analysing about six well known open-source projects.

Haskell in Green Land: Analyzing the Energy Behavior of a Purely Functional Language

Recent work has studied the effect that factors such as code obfuscation, refactorings and data types have on energy efficiency. In this paper, we attempt to shed light on the energy behavior of programs written in a lazy purely functional language, Haskell. We have conducted two empirical studies to analyze the energy efficiency of Haskell programs from two different perspectives: strictness and concurrency. Our experimental space exploration comprises more than 2000 configurations and 20000 executions. We found out that small changes can make a big difference in terms of energy consumption. For example, in one of our benchmarks, under a specific configuration, choosing one data sharing primitive (MVar) over another (TMVar) can yield 60% energy savings. In another benchmark, the latter primitive can yield up to 30% energy savings over the former. Thus, tools that support developers in quickly refactoring a program to switch between different primitives can be of great help if energy is a concern. In addition, the relationship between energy consumption and performance is not always clear. In sequential benchmarks, high performance is an accurate proxy for low energy consumption. However, for one of our concurrent benchmarks, the variants with the best performance also exhibited the worst energy consumption. To support developers in better understanding this complex relationship, we have extended two existing performance analysis tools to also collect and present data about energy consumption.

Assessing Intra-application Exception Handling Reuse with Aspects

Recent studies have attempted to evaluate the benefits and drawbacks of using aspect-oriented programming to modularize exception handling code. In spite of their many interesting findings, these studies have not reached a consensus when it comes to the impact of aspectization on exception handler reuse. In fact, their results are sometimes in direct contradiction.In this paper we describe a study aiming to answer the question of whether AOP really promotes the implementation of reusable exception handling. We analyze reuse in a specific context: in terms of the number of duplicated or very similar error handlers that can be removed from a program when extracting error handling code to aspects. Our study targets three industrial-strength, medium-size software systems from different domains and employs a comprehensive set of concern-specific metrics.

Exception Flows Made Explicit: An Exploratory Study

Most of the exceptions exert a global design impact as they tend to flow through multiple module interfaces of a software system. Exception handling mechanisms in programming languages were originally proposed to improve the robustness and comprehension of error handling code. These mechanisms are traditionally based on the fundamental assumption that global exception flows should be always implicit. However, it has been empirically found that the implementation of global exception handling in real-life software projects tends to exhibit poor quality. This paper presents an exploratory study to assess the benefits and drawbacks of explicit exception flows (or exception channels), as opposed to implicit exception flows. The experiment design involved 15 participants using three alternative mechanisms for exception handling. Our analysis was driven by key indicators of software usability: (i) implementation time, (ii) number of uncaught exceptions, and (iii) number of incorrect answers by the participants.

A systematic review of design diversity-based solutions for fault-tolerant SOAs

Context: Over recent years, software developers have been evaluating the benefits of both Service-Oriented Architecture and software fault tolerance techniques based on design diversity by creating fault-tolerant composite services that leverage functionally equivalent services, or variant services. Three major design issues need to be considered while building software fault-tolerant architectures based on design diversity namely, selection and execution of variants and selection of an adjudication algorithm to determine the correct or adjudicated result from the variants. Each design issue, in turn, can be realized by a set of alternative design solutions, which present different degrees of quality requirements (e.g. memory consumption and reliability). Objective: To investigate whether existing approaches for fault-tolerant composite services support the above mentioned design issues and to provide a detailed classification of the analysed approaches. Method: A systematic literature review of diversity-based approaches for fault-tolerant composite services, which compose our primary studies. Results: We found 17 primary studies providing direct evidence about the research question. Our findings reveal that the primary studies support a wide variety of design decisions. For example, (i) variant services may be chosen at different points during the software lifecycle; (ii) both parallel and sequential execution schemes have been addressed; and (iii) a variety of adjudication mechanisms were found amongst the target papers. Conclusion: We build up a broad picture of what design issues have been addressed by existing diversity-based approaches for fault-tolerant composite services. Finally, practical issues and difficulties are summarized and directions for future work are suggested.

Assessing the impact of AOSD on layered software architectures

Software structuring techniques aim to make software systems easier to develop and maintain, increasing their quality. Aspect-Oriented Software Development (AOSD) and Software Architectural Styles are examples of such techniques. In spite of all the benefits of structuring techniques, both actual and intended, it is not always easy or even advantageous to integrate two or more of these techniques. For example, the effects of combining AOSD and Layered Software Architectures are still not well understood. This might be detrimental to system quality and can be a decisive factor when deciding whether or not to employ AOSD, specially considering the pervasiveness of layered architectures. This paper presents a study aiming to assess the impact of AOSD on software architectures adopting the layered style. To better account for the influence of aspects on the layered structure of the system, we have extended existing approaches to measure dependencies and layering violations in software architectures.

A Comprehensive Study on the Energy Efficiency of Java’s Thread-Safe Collections

Java programmers are served with numerous choices of collections, varying from simple sequential ordered lists to sophisticated hashtable implementations. These choices are well-known to have different characteristics in terms of performance, scalability, and thread-safety, and most of them are well studied. This paper analyzes an additional dimension, energy efficiency. We conducted an empirical investigation of 16 collection implementations (13 thread-safe, 3 non-thread-safe) grouped under 3 commonly used forms of collections (lists, sets, and mappings). Using micro-and real world-benchmarks (Tomcat and Xalan), we show that our results are meaningful and impactful. In general, we observed that simple design decisions can greatly impact energy consumption. In particular, we found that using a newer hashtable version can yield a 2.19x energy savings in the micro-benchmarks and up to 17% in the real world-benchmarks, when compared to the old associative implementation. Also, we observed that different implementations of the same thread-safe collection can have widely different energy consumption behaviors. This variation also applies to the different operations that each collection implements, e.g, a collection implementation that performs traversals very efficiently can be more than an order of magnitude less efficient than another implementation of the same collection when it comes to insertions.

A design rule language for aspect-oriented programming

HighlightsWe present a design rule specification language for aspect-oriented systems.We explore its benefits to supporting the modular development of classes and aspects.We discuss how our language improves crosscutting modularity without breaking class modularity.We present a Compiler for LSD and AspectJ (COLA), a tool to automate design rules checking.We evaluate it using a real case study and compare it with other approaches. Aspect-oriented programming is known as a technique for modularizing crosscutting concerns. However, constructs aimed to support crosscutting modularity might actually break class modularity. As a consequence, class developers face changeability, parallel development and comprehensibility problems, because they must be aware of aspects whenever they develop or maintain a class. At the same time, aspects are vulnerable to changes in classes, since there is no contract specifying the points of interaction amongst these elements. These problems can be mitigated by using adequate design rules between classes and aspects. We present a design rule specification language and explore its benefits since the initial phases of the development process, specially with the aim of supporting modular development of classes and aspects. We discuss how our language improves crosscutting modularity without breaking class modularity. We evaluate it using a real case study and compare it with other approaches.