Intraprocedural Dataﬂow Analysis for Software Product Lines Claus Brabrand 1,2 M´ arcio Ribeiro 2,3 T´ arsis Tolˆ edo 2 Paulo Borba 2 1 IT University of Copenhagen, Rued Langgaards Vej 7, DK-2300, Copenhagen, Denmark 2 Federal University of Pernambuco, Av. Prof. Luis Freire, 50.740-540, Recife, Brazil 3 Federal University of Alagoas, Av. Lourival de Melo Mota, 57.072-970, Macei´ o, Brazil {brabrand@itu.dk, {mmr3, twt, phmb}@cin.ufpe.br} Abstract Software product lines (SPLs) are commonly developed us- ing annotative approaches such as conditional compilation that come with an inherent risk of constructing erroneous products. For this reason, it is essential to be able to an- alyze SPLs. However, as dataﬂow analysis techniques are not able to deal with SPLs, developers must generate and analyze all valid methods individually, which is expensive for non-trivial SPLs. In this paper, we demonstrate how to take any standard intraprocedural dataﬂow analysis and au- tomatically turn it into a feature-sensitive dataﬂow analy- sis in three different ways. All are capable of analyzing all valid methods of an SPL without having to generate all of them explicitly. We have implemented all analyses as exten- sions of SOOT’s intraprocedural dataﬂow analysis frame- work and experimentally evaluated their performance and memory characteristics on four qualitatively different SPLs. The results indicate that the feature-sensitive analyses are on average 5.6 times faster than the brute force approach on our SPLs, and that they have different time and space tradeoffs. Categories and Subject Descriptors D.2.4 [Software En- gineering]: Software/Program Veriﬁcation; F.3.2 [Theory of Computation]: Semantics of Programming Languages — Program Analysis General Terms Performance, Experimentation, Design Keywords Dataﬂow Analysis, Software Product Lines. 1. Introduction A software product line (SPL) is a set of software prod- ucts that share common functionality and are generated from Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for proﬁt or commercial advantage and that copies bear this notice and the full citation on the ﬁrst page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior speciﬁc permission and/or a fee. AOSD’12, March 25–30, 2012, Potsdam, Germany. Copyright c  2012 ACM 978-1-4503-1092-5/12/03. . . $10.00 reusable assets. These assets specify common and variant behavior targeted at a speciﬁc set of products, usually bring- ing productivity and time-to-market improvements [7, 24]. Developers often implement variant behavior and associ- ated features with conditional compilation constructs like #ifdef [1, 16], mixing common, optional, and even alter- native and conﬂicting behavior in the same code asset. In these cases, assets are not valid programs or program ele- ments in the underlying language. We can, however, use as- sets to generate valid programs by evaluating the conditional compilation constructs using preprocessing tools. Since code assets might not be valid programs or program elements, existing standard dataﬂow analyses, which are for instance essential for supporting optimization [18] and main- tenance [26] tasks, cannot be directly used to analyze code assets. To analyze an SPL using intraprocedural analysis, de- velopers then have to generate all possible methods and sep- arately analyze each one with conventional single-program dataﬂow analyses. In this case, generating and analyzing each method can be expensive for non-trivial SPLs. Con- sequently, interactive tools for single-program development might not be usable for SPL development because they rely on fast dataﬂow analyses and have to be able to quickly re- spond when the programmer performs tasks such as code refactoring [10]. Also, this is bad for maintenance tools [26] that help developers understand and manage dependencies between features. To solve this problem and enable more efﬁcient dataﬂow analysis of SPLs, we propose three approaches for taking any standard intraprocedural dataﬂow analysis and automat- ically lifting it into a corresponding feature-sensitive analy- sis that we can use to directly analyze code assets. The ap- proaches analyze all conﬁgurations and thus avoid explic- itly generating all possible methods of an SPL. Although we focus on SPLs developed with conditional compilation con- structs, our results apply to other similar annotative variabil- ity mechanisms [16]. We evaluate our three feature-sensitive approaches (con- secutive, simultaneous, and shared simultaneous) and com- pare them with a brute force intraprocedural approach that