Intraprocedural Dataflow Analysis for Software Product Lines Claus

Intraprocedural Dataflow Analysis for Software Product Lines Claus Brabrand Márcio Ribeiro IT University of Copenhagen Universidade Federal de Pernambuco Universidade Federal de Alagoas Universidade Federal de Pernambuco [ brabrand@itu. dk ] [ mmr 3@cin. ufpe. br ] Társis Tolêdo Universidade Federal de Pernambuco [ twt@cin. ufpe. br ] DAGSTUHL Johnni Winther Paulo Borba Aarhus University Universidade Federal de Pernambuco [ jw@cs. au. dk ] [ phmb@cin. ufpe. br ] Dataflow Analysis for Software Product Lines Feb, 2013

< Outline > Introduction (Software Product Lines) Dataflow Analyses for Software Product Lines: A 0 (brute force): A 1 (consecutive): A 2 (simultaneous): A 3 (shared simul. ): (feature in-sensitive) (feature sensitive) [product-based] [family-based] Results: A 0 vs A 1 vs A 2 vs A 3 (total time, incl. compilation) A 1 vs A 2 vs A 3 (analysis time, excl. compilation) How to combine the analyses: A* Conclusion(s) DAGSTUHL Dataflow Analysis for Software Product Lines [2] Feb, 2013

Software Product Line SPLs based on Conditional Compilation: : f F | | #ifdef ( ). . . (SPL fragment) Example #endif Logo logo; . . . #ifdef (VIDEO) logo = new Logo(); #endif. . . logo. use(); DAGSTUHL *** null-pointer exception! in configurations: {Ø, {COLOR}} Similarly for; e. g. : ■ uninitialized vars ■ unused variables ■. . . Dataflow Analysis for Software Product Lines [3] Feb, 2013

Analysis of SPLs The Compilation Process: compile 0100101 1110110 1010011 1110111 run result ERROR! ANALYZE! . . . and for Software Product Lines: ate gener compile 2 F ANALYZE! 0100101 1110110 1010011 1110111 run run result ERROR! Feature-sensitive data-flow analysis ! DAGSTUHL Dataflow Analysis for Software Product Lines [4] Feb, 2013

Dataflow Analysis: Example: "sign-of-x analysis" 1) Control-flow graph 2) Lattice (finite height) 3) Transfer functions (monotone) L DAGSTUHL Dataflow Analysis for Software Product Lines [5] Feb, 2013

Analyzing a Program 1) Program 2) Build CFG 3) Make Equations Annotated with program points 4) Solve equations: fixed-point computation (iteration) 5) SOLUTION (least fixed point): DAGSTUHL Dataflow Analysis for Software Product Lines [6] Feb, 2013

< Outline > Introduction Dataflow Analyses for Software Product Lines: A 0 (brute force): A 1 (consecutive): A 2 (simultaneous): A 3 (shared simul. ): (feature in-sensitive) (feature sensitive) [product-based] [family-based] Results: A 0 vs A 1 vs A 2 vs A 3 (total time, incl. compilation) A 1 vs A 2 vs A 3 (analysis time, excl. compilation) How to combine the analyses: A* Conclusion(s) DAGSTUHL Dataflow Analysis for Software Product Lines [7] Feb, 2013

A 0 feature in-sensitive! L A 0 (brute force): N = O(2 F) compilations! void m() { int x=0; ifdef(A) x++; ifdef(B) x--; } ψFM = A∨B c = {A}: c = {B}: c = {A, B}: _| _| _| int x = 0; 0 0 0 x++; + x--; + - 0/+ DAGSTUHL Dataflow Analysis for Software Product Lines [8] Feb, 2013

A 1 feature sensitive! L A 1 (consecutive): c = {A}: c = {B}: c = {A, B}: _| _| _| int x = 0; ✓ int x = 0; 0 A: void m() { int x=0; ifdef(A) x++; ifdef(B) x--; } ψFM = A∨B x++; ✓ 0 0 ✓ A: x++; ✓ ✓ ✗ + + B: x--; ✗ B: x--; DAGSTUHL ✓ ✓ Dataflow Analysis for Software Product Lines 0/+ [9] Feb, 2013

A 2 feature sensitive! L A 2 (simultaneous): void m() { int x=0; ifdef(A) x++; ifdef(B) x--; } ψFM = A∨B ∀c ∈{{A}, {B}, {A, B}}: ({A} = _| , ✓ {B} = _| , ✓ {A, B} = _| ) ✓ int x = 0; ({A} = 0, ✓ A: ({A} = DAGSTUHL ✗ {A, B} = 0) ✓ x++; +, ✗ B: ({A} = {B} = 0 , {B} = , ✓ {A, B} = +) ✓ x--; , {B} = -, {A, B} = 0/+ ) Dataflow Analysis for Software Product Lines [ 10 ] Feb, 2013

A 3 feature sensitive! L A 3 (shared): void m() { int x=0; ifdef(A) x++; ifdef(B) x--; } ψFM = A∨B: ( [[ψ]] = _| ) int x = 0; can use BDD ( [[ψ]] = 0 ) (A∨B)∧¬A∧¬B ≡ false i. e. , invalid given wrt. the feature model, ψ ! A: ( [[ψ∧¬A]] = B: ( [[ψ∧¬A ∧¬B ]] = DAGSTUHL , [[ψ∧A∧¬B ]] = representation ! x++; 0 , [[ψ∧A]] = (compact+efficient) (although our evaluation: bit vector representation) +) x--; , [[ψ∧¬A∧B ]] = - , [[ψ∧A∧B ]] = Dataflow Analysis for Software Product Lines [ 11 ] 0/+ ) Feb, 2013

Summary A 1 A 0 A 3 A 2 DAGSTUHL Analyzing program: void m() { int x=0; ifdef(A) x++; ifdef(B) x--; } ψFM = A∨B Dataflow Analysis for Software Product Lines [ 12 ] Feb, 2013

< Outline > Introduction Dataflow Analyses for Software Product Lines: A 0 (brute force): A 1 (consecutive): A 2 (simultaneous): A 3 (shared simul. ): (feature in-sensitive) (feature sensitive) [product-based] [family-based] Results: A 0 vs A 1 vs A 2 vs A 3 (total time, incl. compilation) A 1 vs A 2 vs A 3 (analysis time, excl. compilation) How to combine the analyses: A* Conclusion(s) DAGSTUHL Dataflow Analysis for Software Product Lines [ 13 ] Feb, 2013

Intraprocedural Evaluation Five (qualitatively different) SPL benchmarks: intraprocedural impl based on SOOT and CIDE DAGSTUHL Dataflow Analysis for Software Product Lines [ 14 ] Feb, 2013

Total Time (incl. compile) Tasks: In practice: (Reaching Definitions) Feature sensitive (A 1, A 2, and A 3) all faster than A 0 4 x 7 x (no re-compile!) 1 x 1 x 3 x DAGSTUHL Dataflow Analysis for Software Product Lines [ 15 ] Feb, 2013

Analysis Time (excl. compile) Tasks: In practice: (Reaching Definitions) A 2 faster than A 1 (caching!) A 3 faster than A 2 (sharing!) DAGSTUHL Dataflow Analysis for Software Product Lines [ 16 ] Feb, 2013

Beyond the Sum of all Methods For a method with x # valid configurations, which of analyses A 1 vs A 2 vs A 3 is fastest? Statistically significant differences between A 1, A 2, and A 3 for all N, except between A 2 and A 3 for N=4 (underlined above). DAGSTUHL Dataflow Analysis for Software Product Lines [ 17 ] Feb, 2013

Combo Analysis Strategy: A* Intraprocedurally combined analysis strategy, A*: A* consistently fastest (combo!) DAGSTUHL Dataflow Analysis for Software Product Lines [ 18 ] Feb, 2013

< Outline > Introduction Dataflow Analyses for Software Product Lines: A 0 (brute force): A 1 (consecutive): A 2 (simultaneous): A 3 (shared simul. ): (feature in-sensitive) (feature sensitive) [product-based] [family-based] Results: A 0 vs A 1 vs A 2 vs A 3 (total time, incl. compilation) A 1 vs A 2 vs A 3 (analysis time, excl. compilation) How to combine the analyses: A* Conclusion(s) DAGSTUHL Dataflow Analysis for Software Product Lines [ 19 ] Feb, 2013

Overview "SPLLIFT: Transparent and Efficient Reuse of IFDS-based Static Program Analyses for Software Product Lines" ( Bodden, Ribeiro, Tolêdo, Brabrand, Borba, Mezini ) y a d i Fr PLDI 2013: IFDS➞IDE (lift) A* (combo) (intra-procedural) A 3+BDD combo! (esp. interprocedural) repr! A 3 (shared) FASTER sharing! A 2 (simultaneous) caching! A 1 (consecutive) no re-compile! IFDS (graph repr) graph encoding! A 0 (brute force) DAGSTUHL Dataflow Analysis for Software Product Lines [ 20 ] Feb, 2013

Conclusion(s) It is possible to analyze SPLs using DFAs We can automatically "lift" any dataflow analysis and make it feature sensitive: A 1 (consecutive) ➞ A 2 (simultaneous) ➞ A 3 (shared) ➞ A* (combined) A 1, A 2, A 3 are all faster than A 0 A 2 is faster than A 1 A 3 is faster than A 2 A* is fastest (no re-compile!) (caching!) (sharing!) (combo!) A 3 saves lots of memory vs A 2 DAGSTUHL Dataflow Analysis for Software Product Lines (sharing!) [ 21 ] Feb, 2013

< Obrigado* > *) Thanks DAGSTUHL Dataflow Analysis for Software Product Lines Feb, 2013

A 0 vs IFDS A 0: and A 2 vs SPLLIFT IFDS: {x} 0 x y λS. (S – {x}) ∪ {y} LIFT: A 2: SPLLIFT (IFDS ➞ IDE): ( {A} = {x} , {B} = {x} , {A, B} = {x, y} ) DAGSTUHL ¬A A A: λS. (S – {x}) ∪ {y} A∧B y x 0 #ifdef (A) ( {A} = {y} , {B} = {x} , {A, B} = {y} ) true ¬A 0 x true∧¬A = ¬A [ (A∧B)∧¬A] ∨ [ true∧A] =A [ 23 ] Feb, 2013 Dataflow Analysis for Software Product Lines y

INTRO: Software Product Lines Dataflow Analysis DAGSTUHL Dataflow Analysis for Software Product Lines Feb, 2013

Abstract Software product lines (SPLs) developed using annotative approaches such as conditional compilation come with an inherent risk of constructing erroneous products. For this reason, it is essential to be able to analyze such SPLs. However, as dataflow analysis techniques are not able to deal with SPLs, developers must generate and analyze all valid products individually, which is expensive for non-trivial SPLs. In this paper, we demonstrate how to take any standard intraprocedural dataflow analysis and automatically turn it into a feature-sensitive dataflow analysis in five different ways where the last is a combination of the other four. All analyses are capable of analyzing all valid products of an SPL without having to generate all of them explicitly. We have implemented all analyses using SOOT’s intraprocedural dataflow analysis framework and experimentally evaluated four of them according to their performance and memory characteristics on five qualitatively different SPLs. On our benchmarks, the combined analysis strategy is up to almost eight times faster than the brute-force approach. DAGSTUHL Dataflow Analysis for Software Product Lines [ 25 ] Feb, 2013

< Outline > Introduction Software Product Lines Dataflow Analysis (recap) Dataflow Analyses for Software Product Lines: feature in-sensitive (A 0) vs feature sensitive (A 1, A 2, A 3) Results: A 0 vs A 1 vs A 2 vs A 3 (in theory and practice) Related Work Conclusion DAGSTUHL Dataflow Analysis for Software Product Lines [ 26 ] Feb, 2013

Introduction Traditional Software Development: One program = One product = = 1 x CAR 1 x CELL PHONE = 1 x APPLICATION Product Line: A ”family” of products (of N ”similar” products): CARS CELL PHONES customize APPLICATIONS SPL: (Family of Programs) DAGSTUHL Dataflow Analysis for Software Product Lines [ 27 ] Feb, 2013

Software Product Line SPL: COLOR Ø cus VIDEO Family of Programs: ize m to { Color } 2 F COLOR VIDEO { Video } VIDEO Set of Features: F = { COLOR, VIDEO } { Color, Video } Feature Model: (e. g. : ψFM ≡ VIDEO COLOR) DAGSTUHL VALID Configurations: 2 F Ø, {Color}, {Video}, {Color, Video} Dataflow Analysis for Software Product Lines [ 28 ] Feb, 2013

Software Product Line Conditional compilation: SPL: VIDEO Family of Program s: COLOR VIDEO : f F | #ifdef ( ) | Alternatively, via Aspects (as in AOSD) . . . #endif (SPL fragment) Example VIDEO Logo logo; . . . #ifdef (VIDEO) logo = new Logo(); #endif. . . logo. use(); DAGSTUHL *** null-pointer exception! in configurations: {Ø, {COLOR}} Similarly for; e. g. : ■ uninitialized vars ■ unused variables ■. . . Dataflow Analysis for Software Product Lines [ 29 ] Feb, 2013

Analysis of SPLs The Compilation Process: compile 0100101 1110110 1010011 1110111 run result ERROR! ANALYZE! . . . and for Software Product Lines: customize compile 2 F ANALYZE! 0100101 1110110 1010011 1110111 run run result ERROR! Feature-sensitive data-flow analysis ! DAGSTUHL Dataflow Analysis for Software Product Lines [ 31 ] Feb, 2013

< Outline > Introduction Software Product Lines Dataflow Analysis (recap) Dataflow Analyses for Software Product Lines: feature in-sensitive (A 0) vs feature sensitive (A 1, A 2, A 3) Results: A 0 vs A 1 vs A 2 vs A 3 (in theory and practice) Related Work Conclusion DAGSTUHL Dataflow Analysis for Software Product Lines [ 32 ] Feb, 2013

Dataflow Analysis: Example: "sign-of-x analysis" 1) Control-flow graph 2) Lattice (finite height) 3) Transfer functions (monotone) L DAGSTUHL Dataflow Analysis for Software Product Lines [ 33 ] Feb, 2013

Analyzing a Program 1) Program 2) Build CFG 3) Make Equations Annotated with program points 4) Solve equations: fixed-point computation (iteration) 5) SOLUTION (least fixed point): DAGSTUHL Dataflow Analysis for Software Product Lines [ 34 ] Feb, 2013

Related Work: DAGSTUHL Dataflow Analysis for Software Product Lines Feb, 2013

< Outline > Introduction Software Product Lines Dataflow Analysis (recap) Dataflow Analyses for Software Product Lines: feature in-sensitive (A 0) vs feature sensitive (A 1, A 2, A 3) Results: A 0 vs A 1 vs A 2 vs A 3 (in theory and practice) Related Work Conclusion DAGSTUHL Dataflow Analysis for Software Product Lines [ 36 ] Feb, 2013

Related Work (DFA) Path-sensitive DFA: “Constant Propagation with Conditional Branches” ( Wegman and Zadeck ) TOPLAS 1991 Idea of “conditionally executed statements” Compute different analysis info along different paths (~ A 1, A 2, A 3) to improve precision or to optimize “hot paths” Predicated DFA: “Predicated Array Data-Flow Analysis for Run-time Parallelization” ( Moon, Hall, and Murphy ) ICS 1998 Guard lattice values by propositional logic predicates (~ A 3), yielding “optimistic dataflow values” that are kept distinct during analysis (~ A 2 and A 3) Our work: Automatically lift any DFA to SPLs (with ψFM) ⇒ feature-sensitive analysis for analyzing entire program family DAGSTUHL Dataflow Analysis for Software Product Lines [ 37 ] Feb, 2013

Related Work (Lifting for SPLs) Model Checking: Model checks all SPLs at the same time (3. 5 x faster) than one by one! (similar goal, diff techniques) Model Checking Lots of Systems: Efficient Verification of Temporal Properties in Software Product Lines” ( Classen, Heymans, Schobbens, Legay, and Raskin ) ICSE 2010 Type Checking: Type checking ↔ DFA (similar goal, diff techniques) Our: auto lift any DFA (uninit vars, null pointers, . . . ) “Type-Checking Software Product Lines - A Formal Approach” ( Kastner and Apel ) ASE 2008 “Type Safety for Feature-Oriented Product Lines” ( Apel, Kastner, Grösslinger, and Lengauer ) ASE 2010 Parsing: (similar techniques, diff goal): Split and merging parsing (~A 3) and also uses instrumentation “Variability-Aware Parsing in the Presence of Lexical Macros & C. C. ” ( Kastner, Giarrusso, Rendel, Erdweg, Ostermann, and Berger ) OOPSLA 2011 Select relevant feature combinations for a given test case Testing: Uses (hardwired) DFA (w/o FM) to compute reachability “Reducing Combinatorics in Testing Product Lines” ( Hwan, Kim, Batory, and Khurshid ) DAGSTUHL Dataflow Analysis for Software Product Lines AOSD 2011 [ 38 ] Feb, 2013

Emerging Interfaces DAGSTUHL Dataflow Analysis for Software Product Lines [ 39 ] Feb, 2013

Emerging Interfaces CBSoft 2011: *** Best Tool Award *** "A Tool for Improving Maintainability of Preprocessor-based Product Lines" ( Márcio Ribeiro, Társis Tolêdo, Paulo Borba, Claus Brabrand ) DAGSTUHL Dataflow Analysis for Software Product Lines [ 40 ] Feb, 2013

BONUS SLIDES DAGSTUHL Dataflow Analysis for Software Product Lines Feb, 2013

Specification: A 0, A 1, A 2, A 3 A 0 A 1 A 2 A 3 DAGSTUHL Dataflow Analysis for Software Product Lines [ 42 ] Feb, 2013

Analysis Time (excl. compile) In theory: In practice: (Reaching Definitions) TIME(A 3) : Depends on degree of sharing in SPL ! A 2 faster than A 1 (caching!) A 3 faster than A 2 (sharing!) DAGSTUHL Dataflow Analysis for Software Product Lines [ 43 ] Feb, 2013

Memory Usage In theory: In practice: (Reaching Definitions) DAGSTUHL SPACE(A 3) : Depends on degree of sharing in SPL ! Dataflow Analysis for Software Product Lines [ 44 ] Feb, 2013

Analysis Time (excl. compile) Nx 1 ≠ 1 x. N ? ! In practice: (Reaching Definitions) A 2 faster than A 1 Caching! DAGSTUHL Dataflow Analysis for Software Product Lines [ 45 ] Feb, 2013

Caching (A 1 vs A 2) Cache misses (A 1 vs A 2): Cache enabled: This is the "normal condition" (for reference) Cache disabled*: *) we flush the L 2 cache, by traversing an 8 MB “bogus array” to invalidate cache! As hypothesized, this indeed affects A 1 more than A 2 i. e. , A 2 has better cache properties than A 1 DAGSTUHL Dataflow Analysis for Software Product Lines [ 46 ] Feb, 2013

IFDEF normalization Refactor "undisciplined" (lexical) ifdefs into "disciplined" (syntactic) ifdefs: Normalize "ifdef"s (by transformation): DAGSTUHL Dataflow Analysis for Software Product Lines [ 47 ] Feb, 2013

Lexical #ifdef Syntactic ifdef Simple transformation: Nested ifdef's also give rise to a conj. of formulas We do not handle non-syntactic '#ifdef's: Fair assumption (also in CIDE) DAGSTUHL Dataflow Analysis for Software Product Lines [ 48 ] Feb, 2013

BDD (Binary Decision Diagram) Compact and efficient representation for boolean functions (aka. , set of names) F(A, B, C) = A BDD B C = A B C A (B C) C C �� �� minimized BDD B C � � FAST: negation, conjunction, disjunction, equality ! DAGSTUHL Dataflow Analysis for Software Product Lines [ 49 ] Feb, 2013

Formula ~ Set of Configurations Definitions (given F, set of feature names): f F feature name c 2 F configuration (set of feature names) X 22 F set of config's (set of feature names) Example ifdefs: DAGSTUHL [[ B A ]] = { {A}, {B}, {A, B} } [[ A (B C) ]] = { {A, B}, {A, C}, {A, B, C} } Dataflow Analysis for Software Product Lines c F X 2 F F = {A, B} F = {A, B, C} [ 50 ] Feb, 2013

Feature Model (Example) Air Feature Model: Note: | [[ FM]] | = 3 < 32 = |2 F | Engine Feature set: F = {Car, Engine, 1. 0, 1. 4, Air} Air 1. 0 Formula: [[ FM Car Engine (1. 0 1. 4) Air 1. 4 Set of configurations: 1. 4 ]] = { {Car, Engine, 1. 0}, {Car, Engine, 1. 4, Air} } DAGSTUHL Dataflow Analysis for Software Product Lines [ 51 ] Feb, 2013

Conditional Compilation The 'ifdef' construction: STM : A 'ifdef' '(' ')' STM Syntactic variant of lexical #ifdef (A) {. . . } Propositional Logic: : f F | | where f F (finite set of feature names) Example: DAGSTUHL status. print("you die"); ifdef (Deluxe. Version && Color. Display) { player. redraw(Color. red); Audio. play("crash. wav"); } lives = lives - 1; Dataflow Analysis for Software Product Lines [ 52 ] Feb, 2013

A 4: Lazy Splitting (using BDDs) CASE 1: "COPY" CASE 2: "APPLY" = = Ø S [ =l , . . . ] DAGSTUHL Ø [ =l , . . . ] l ' = f. S(l ) : S [ =l ', . . . ] [ =l , . . . ] : CASE 3: "SPLIT" [ =l , . . . ] l ' = f. S(l ) : l ' = f. S(l ) S [ =l, =l' , . . . ] Dataflow Analysis for Software Product Lines [ 53 ] Feb, 2013

A 1 A 3 DAGSTUHL A 1, A 2, A 3, and A 4 Dataflow Analysis for Software Product Lines A 2 [ 54 ] A 4 Feb, 2013