1 / 39

Intraprocedural Dataflow Analysis for Software Product Lines

Intraprocedural Dataflow Analysis for Software Product Lines. Claus Brabrand IT University of Copenhagen Universidade Federal de Pernambuco [ brabrand@itu.dk ]. Márcio Ribeiro Universidade Federal de Alagoas Universidade Federal de Pernambuco [ mmr3@cin.ufpe.br ]. Paulo Borba

nita
Download Presentation

Intraprocedural Dataflow Analysis for Software Product Lines

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IntraproceduralDataflow Analysis forSoftware Product Lines Claus Brabrand IT University of Copenhagen Universidade Federal de Pernambuco [ brabrand@itu.dk ] Márcio Ribeiro Universidade Federal de Alagoas Universidade Federal de Pernambuco [ mmr3@cin.ufpe.br ] Paulo Borba Universidade Federal de Pernambuco [ phmb@cin.ufpe.br ] TársisTolêdo Universidade Federal de Pernambuco [ twt@cin.ufpe.br ]

  2. < Outline > • Introduction • Software Product Lines(recap) • Dataflow Analysis (recap) • Dataflow Analyses for Software Product Lines: • feature in-sensitive(A1)vsfeature sensitive(A2, A3, A4) • Results: • A1vsA2vsA3vsA4 (in theory and practice) • Related Work • Conclusion

  3. Introduction • Traditional Software Development: • One program = One product • Product Line: • A ”family” of products (of N ”similar” products): = = = 1x CAR 1x CELL PHONE 1x APPLICATION CARS CELL PHONES APPLICATIONS customize SPL: (Family ofPrograms)

  4. Software Product Line • SPL: • Feature Model: (e.g.: ψFM ≡ VIDEO  COLOR) Ø Family of Programs: customize { Color} COLOR VIDEO 2F COLORVIDEO { Video } VIDEO Features: F = { COLOR, VIDEO } { Color, Video } Configurations: Ø,{Color},{Video},{Color,Video} 2F VALID

  5. Software Product Line Conditional compilation: • SPL: Family of s: Program COLOR VIDEO #ifdef(  ) ... #endif Alternatively,via Aspects(as in AOSD) COLORVIDEO VIDEO *** uninitialized variable!in configurations: {Ø, {COLOR}} Logo logo; ... ... use(logo); #ifdef (VIDEO) logo = new Logo(); #endif Similarly for; e.g.: ■null-pointers ■unused variables ■undefined variables Example:

  6. Analysis of SPLs • The Compilation Process: • ...and for Software Product Lines: 0100101 1110110 1010011 1110111 compile run result ERROR! ANALYZE! 0100101 1110110 1010011 1110111 0100101 1110110 1010011 1110111 run customize compile 0100101 1110110 1010011 1110111 run compile run compile result result result 2F ANALYZE! ERROR! ERROR! ANALYZE! ERROR! ANALYZE! Feature-sensitivedata-flow analysis !

  7. < Outline > • Introduction • Software Product Lines(recap) • Dataflow Analysis (recap) • Dataflow Analyses for Software Product Lines: • feature in-sensitive(A1)vsfeature sensitive(A2, A3, A4) • Results: • A1vsA2vsA3vsA4 (in theory and practice) • Related Work • Conclusion

  8. Dataflow Analysis L • Dataflow Analysis: • 1)Control-flow graph • 2)Lattice(finiteheight) • 3)Transfer functions(monotone) Example: "sign-of-xanalysis"

  9. < Outline > • Introduction • Software Product Lines(recap) • Dataflow Analysis (recap) • Dataflow Analyses for Software Product Lines: • feature in-sensitive(A1)vsfeature sensitive(A2, A3, A4) • Results: • A1vsA2vsA3vsA4 (in theory and practice) • Related Work • Conclusion

  10. A1(brute force) L void m() { int x=0; ifdef(A) x++; ifdef(B) x--; } • A1 (feature in-sensitive): • N = 2Fcompilations! ψFM = A∨B _ _ _ | | | c = {A}: c = {B}: c = {A,B}: int x= 0; int x= 0; int x= 0; 0 0 0 x++; x++; x++; + x--; x--; x--; 0/+ + -

  11. A2(consecutive) L void m() { int x=0; ifdef(A) x++; ifdef(B) x--; } • A2 (feature sensitive!): ψFM = A∨B _ _ _ | | | c = {A}: c = {B}: c = {A,B}: c |- [[true]] c |- [[true]] c |- [[true]] int x= 0; int x= 0; int x= 0; ✓ ✓ ✓ [[true]] [[true]] [[true]] 0 0 0 c |- [[A]] c |- [[A]] c |- [[A]] x++; x++; x++; ✓ ✓ ✗ [[A]] [[A]] [[A]] + + 0 c |- [[B]] c |- [[B]] c |- [[B]] ✓ ✗ ✓ [[B]] [[B]] [[B]] x--; x--; x--; 0/+ + -

  12. A3(simultaneous) L void m() { int x=0; ifdef(A) x++; ifdef(B) x--; } • A3 (feature sensitive!): ψFM = A∨B _ _ _ | | | ∀c∈ {{A},{B},{A,B}}: ({A} = , {B} = , {A,B} = ) ✓ ✓ ✓ ∀c |- [[true]] int x= 0; [[true]] 0 0 0 ({A} = , {B} = , {A,B} = ) ✗ ✓ ✓ ∀c |- [[A]] x++; [[A]] + + 0 ({A} = , {B} = , {A,B} = ) ✗ ✓ ✓ ∀c |- [[B]] [[B]] x--; 0/+ + - ({A} = , {B} = , {A,B} = )

  13. A4(shared) L void m() { int x=0; ifdef(A) x++; ifdef(B) x--; } • A4 (feature sensitive!): ψFM = A∨B _ | ψFM = A∨B: ( [[ψ]] = ) int x= 0; [[true]] 0 ( [[ψ]] = ) …using BDD representation! (compact+efficient) x++; [[A]] (A∨B)∧¬A∧¬B ≡ false i.e., invalid given wrt.the feature model, ψ! 0 + ( [[ψ∧¬A]] = , [[ψ∧A]] = ) [[B]] x--; - 0/+ + 0 ( [[ψ∧¬A∧¬B]] = , [[ψ∧A∧¬B]] = , [[ψ∧¬A∧B]] = , [[ψ∧A∧B]] = )

  14. < Outline > • Introduction • Software Product Lines(recap) • Dataflow Analysis (recap) • Dataflow Analyses for Software Product Lines: • feature in-sensitive(A1)vsfeature sensitive(A2, A3, A4) • Results: • A1vsA2vsA3vsA4 (in theory and practice) • Related Work • Conclusion

  15. Evaluation • Four (qualitatively different)SPL benchmarks: • Implementation:A1, A2, A3, A4 in SOOT + CIDE • Evaluation:total time, analysis time, memory usage

  16. Results (total time) • In theory: • In practice: 2F 2F 2F Feature sensitive (avg. gain factor): A2 (3x), A3 (4x), A4 (5x) (Reaching Definitions) 1x 1x 1x 2x 2x 2½x 3x 3x 5x 6x 8x 14x

  17. Results (analysis time) • In theory: • In practice: A2 2F A3 vs On average (A2 vs A3): TIME(A4) : Depends ondegree of sharing in SPL ! A3 (1.5x) faster (Reaching Definitions) (caching!)

  18. Results (memory usage) • In theory: • In practice: A2 A3 vs 2F SPACE(A4) : Depends ondegree of sharing in SPL ! Average 6.3 : 1 (Reaching Definitions)

  19. < Outline > • Introduction • Software Product Lines(recap) • Dataflow Analysis (recap) • Dataflow Analyses for Software Product Lines: • feature in-sensitive(A1)vsfeature sensitive(A2, A3, A4) • Results: • A1vsA2vsA3vsA4 (in theory and practice) • Related Work • Conclusion

  20. Related Work (DFA) • Path-sensitive DFA: • Idea of “conditionally executed statements” • Compute different analysis info along different paths (~ A2, A3, A4) to improve precision or to optimize “hot paths” • Predicated DFA: • Guard lattice values by propositional logic predicates (~ A4), yielding “optimistic dataflow values” that are kept distinct during analysis (~ A3and A4) “Constant Propagation with Conditional Branches” ( Wegman and Zadeck ) TOPLAS 1991 “Predicated Array Data-Flow Analysis for Run-time Parallelization” ( Moon, Hall, and Murphy ) ICS 1998 Our work:Automatically lift anyDFA to SPLs (with ψFM) ⇒feature-sensitive analysis for analyzing entire program family

  21. Related Work (Lifting for SPLs) • Model Checking: • Type Checking: • Parsing: • Testing: Model checks all SPLs at the same time (3.5x 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 ↔ DFA (similar goals, diff techniques) Our: auto lift any DFA (uninitvars, null pointers, ...) “Type-Checking Software Product Lines - A Formal Approach” ( Kastnerand Apel ) ASE 2008 “Type Safety for Feature-Oriented Product Lines” ( Apel, Kastner, Grösslinger, and Lengauer) ASE 2010 (similar techniques, diff goal): Split and merging parsing (~A4) 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 Uses (hardwired) DFA (w/o FM) to compute reachability “Reducing Combinatorics in Testing Product Lines” ( Hwan, Kim, Batory, and Khurshid) AOSD 2011

  22. Related Work (emerging interfaces) • Emerging Interfaces: Compute E.I. to flag dependencies and howedit in one place affect feature(s) elsewhere “Emergent Feature Modularization” ( Ribeiro, Pacheco, Teixeira, and Borba ) Onward! 2010 “EMERGO: A Tool for Improving Maintainability of Preprocessor-Based PLs” ( Ribeiro, Tolêdo, Winther, Brabrand, and Borba ) AOSD Tool Demo 2012 TOOL DEMO “EMERGO: A Tool for Improving Maintainability of Preprocessor-Based Product Lines” Thursday at 14:00 and Friday at 16:00 AOSD 2012

  23. < Outline > • Introduction • Software Product Lines(recap) • Dataflow Analysis (recap) • Dataflow Analyses for Software Product Lines: • feature in-sensitive(A1)vsfeature sensitive(A2, A3, A4) • Results: • A1vsA2vsA3vsA4 (in theory and practice) • Related Work • Conclusion

  24. Conclusion(s) • It is possible to analyzeSPLsusingDFAs • Wecanautomatically"lift"anydataflowanalysis and make it feature sensitive: • A2)Consecutive • A3)Simultaneous • A4)Shared Simultaneous • A2,A3,A4much faster (3x,4x,5x) than naive A1 • A3 is (1.5x) faster thanA2 (caching!) • A4saves lots of memoryvsA3(sharing!) 6.3 : 1

  25. < Obrigado*> *)Thanks

  26. BONUS SLIDES

  27. Future Work • Explorehow all thisscales to…: • In particular: • …relative speed of A1vsA2vsA3vsA4 ? • …which analyses arefeasiblevsin-feasible? INTER-procedural data-flow analysis In progress...!

  28. Specification: A1, A2, A3, A4 A1 A2 A3 A4

  29. Results (analysis time) ?! • In theory: • In practice: A2 (caching!) Nx1 ≠ 1xN 2F A3 2F vs On average (A2 vs A3): TIME(A4) : Depends ondegree of sharing in SPL ! A3 (1.5x) faster (Reaching Definitions)

  30. A2vsA3(caching) • Cache misses inA2vsA3: • Normal cache: • As expected, A2incurs more cache misses (⇒ slower!) • Full/no cache*: • As hypothesized, this indeed affects A2more than A3 • i.e.,A3has better cache properties thanA2 A2 A3 vs *) we flush the L2 cache, by traversing an8MB “bogus array” to invalidate cache!

  31. Analyzing a Program 1)Program 2)Build CFG 3)Make Equations 4)Solveequations: fixed-point computation(iteration) 5) SOLUTION (least fixed point):

  32. IFDEF normalization • Refactor"undisciplined"(lexical) ifdefs into "disciplined"(syntactic) ifdefs: • Normalize "ifdef"s (by transformation):

  33. Feature Model (Example) Note: | [[FM]]| = 3<32 = |2F | • Feature Model: • Feature set: • Formula: • Set of configurations: F = {Car, Engine, 1.0, 1.4, Air} [[ ]] = FM  Car  Engine  (1.01.4)  Air1.4 { {Car, Engine, 1.0}, {Car, Engine, 1.4}, {Car, Engine, 1.4, Air} }

  34. Example Bug from Lampiro • Lampiro SPL (IM client for XMPP protocol): *** uninitialized variable "logo" • (if feature "GLIDER" is defined) • Similar problems with: • undeclared variables, unused variables, null pointers, ...

  35. BDD (Binary Decision Diagram) =  F(A,B,C)= A(BC) A A BDD minimized BDD B B B C C C C C           • Compact and efficientrepresentation forboolean functions (aka., set of set of names) • FAST: negation, conjunction, disjunction, equality ! 

  36. Formula ~ Set of Configurations • Definitions (given F, set of feature names): • f Ffeature name • c 2Fconfiguration(set of feature names) cF • X  22set of config's (set of set of feature names)X 2F • Exampleifdefs: F [[ BA]] = { {A}, {B}, {A,B} } F = {A,B} [[ A(BC)]] F = {A,B,C} = { {A,B}, {A,C}, {A,B,C} }

  37. Emerging Interfaces

  38. Emerging Interfaces CBSoft 2011: *** Best Tool Award *** "A Tool for Improving Maintainability of Preprocessor-based Product Lines" ( MárcioRibeiro, TársisTolêdo, Paulo Borba, Claus Brabrand )

  39. Errors Logo logo; use(logo); #ifdef (VIDEO) logo = new Logo(); #endif • *** uninitialized variable!in configurations: {Ø, {COLOR}} Logo logo; logo.use(); #ifdef (VIDEO) logo = new Logo(); #endif *** null-pointer exception!in configurations: {Ø, {COLOR}} Logo logo; ... • *** unused variable!in configurations: {Ø, {COLOR}} #ifdef (VIDEO) logo = new Logo(); #endif

More Related