intraprocedural dataflow analysis for software product lines n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Intraprocedural Dataflow Analysis for Software Product Lines PowerPoint Presentation
Download Presentation
Intraprocedural Dataflow Analysis for Software Product Lines

Loading in 2 Seconds...

play fullscreen
1 / 39

Intraprocedural Dataflow Analysis for Software Product Lines - PowerPoint PPT Presentation


  • 63 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Intraprocedural Dataflow Analysis for Software Product Lines' - jirair


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
intraprocedural dataflow analysis for software product lines

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 ]

outline
< 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
introduction
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)

software product line
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

software product line1
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:

analysis of spls
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 !

outline1
< 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
data f low analysis
Dataflow Analysis

L

  • Dataflow Analysis:
      • 1)Control-flow graph
      • 2)Lattice(finiteheight)
      • 3)Transfer functions(monotone)

Example:

"sign-of-xanalysis"

outline2
< 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
a1 brute force
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/+

+

-

a2 consecutive
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/+

+

-

a3 simultaneous
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} = )

a4 shared
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]] = )

outline3
< 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
evaluation
Evaluation
  • Four (qualitatively different)SPL benchmarks:
      • Implementation:A1, A2, A3, A4 in SOOT + CIDE
      • Evaluation:total time, analysis time, memory usage
results total time
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

results analysis time
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!)

results memory usage
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)

outline4
< 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
related work dfa
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

related work lifting for spls
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

related work emerging interfaces
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

outline5
< 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
conclusion s
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

obrigado

< Obrigado*>

*)Thanks

future work
Future Work
  • Explorehow all thisscales to…:
  • In particular:
      • …relative speed of A1vsA2vsA3vsA4 ?
      • …which analyses arefeasiblevsin-feasible?

INTER-procedural

data-flow analysis

In progress...!

results analysis time1
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)

a2 vs a3 caching
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!

analyzing a program
Analyzing a Program

1)Program

2)Build CFG

3)Make Equations

4)Solveequations: fixed-point computation(iteration)

5) SOLUTION (least fixed point):

ifdef normalization
IFDEF normalization
  • Refactor"undisciplined"(lexical) ifdefs into "disciplined"(syntactic) ifdefs:
  • Normalize "ifdef"s (by transformation):
feature model example
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} }

example bug from lampiro
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, ...
bdd binary decision diagram
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 !

formula set of configurations
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} }

emerging interfaces1
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 )

errors
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