Dataflow Analysis for Software Product Lines - PowerPoint Presentation

Slide1

Dataflow Analysis forSoftware Product Lines

Claus BrabrandIT University of CopenhagenUniversidade Federal de Pernambuco[ brabrand@itu.dk ]

Márcio RibeiroUniversidade Federal de AlagoasUniversidade Federal de Pernambuco[ mmr3@cin.ufpe.br ]

Paulo BorbaUniversidade Federal de Pernambuco[ phmb@cin.ufpe.br ]

Társis TolêdoUniversidade Federal de Pernambuco[ twt@cin.ufpe.br ]

Slide2

AbstractSoftware product lines (SPLs) are commonly developed using 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 analyze SPLs. However, as dataflow 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 intraprocedural standard dataflow analysis and automatically turn it into a /feature-sensitive

/ dataflow analysis 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 extensions of SOOT's intraprocedural dataflow analysis framework and experimentally evaluated their performance and memory characteristics on four qualitatively different SPLs.The results indicate that the feature-sensitive analyses are respectively on average three, four, and five times faster than the naive brute

force approach on our SPLs, and that they have different time and space tradeoffs.

Slide3

< Outline >Introduction

Software Product LinesDataflow Analysis (recap)Dataflow Analyses for Software Product Lines:feature in-

sensitive (A1) vs feature sensitive (A2, A3,

A4)Results:A1 vs A2 vs A3 vs A4 (in theory and practice)

Related WorkConclusion

Slide4

Introduction

1x CAR

=

1x CELL PHONE

=

1x APPLICATION

=

CARS

CELL PHONES

APPLICATIONS

Traditional

Software Development:

One program = One

product

Product Line:

A

”

family

”

of products

(of N ”

similar

” products):

customize

SPL

:

(Family of

Programs)

Slide5

Software Product LineSPL:

Feature Model: (e.g

.: ψFM ≡ VIDEO  COLOR)

Family ofPrograms:

COLOR

VIDEO

COLORVIDEO

VIDEO

Ø

{

Video }

{

Color

, Video

}

Configurations

:

Ø,

{

Color

}

,

{Video}

,

{

Color,Video

}

VALID

{

Color

}

customize

2

F

Set of Features

:

F

= {

COLOR

,

VIDEO

}

2

F

Slide6

Software Product LineSPL:

Family of

s:

COLOR

VIDEOCOLOR

VIDEO

VIDEO

Program

Conditional compilation

:

#

ifdef

(



)

...

#

endif

Alternatively,

via

Aspects

(as in

A

OSD)

Logo logo;

...

...

logo.use

();

#

ifdef

(VIDEO)

logo = new Logo();

#

endif

Example

(SPL fragment

)

Similarly for; e.g.:

■

uninitialized

vars

■

unused variables

■

...

***

null-pointer exception!

in configurations: {Ø, {COLOR}

}



: fF | 

| 

Slide7

ErrorsLogo logo;

logo.use();

#ifdef (VIDEO) logo = new Logo();#endif

*** null-pointer exception!in configurations: {Ø, {COLOR}

}Logo logo;print(logo);

#ifdef (VIDEO) logo = new Logo();

#endif

*** uninitialized variable

!

in configurations: {

Ø

,

{COLOR}

}

Logo logo;

...

#

ifdef

(VIDEO)

logo = new Logo();

#

endif

***

unused variable

!

in configurations: {

Ø

,

{COLOR}

}

Slide8

result

result

0100101

111011010100111110111

0100101111011010100111110111Analysis of SPLsThe Compilation Process:

...and for Software Product Lines:

0100101

111011010100111110111

result

compile

run

ERROR

!

customize

0100101

1110110

1010011

1110111

result

run

ERROR

!

ANALYZE

!

ANALYZE

!

Feature-sensitive

data

-flow

analysis

!

run

run

compile

compile

compile

ANALYZE

!

ANALYZE

!

ERROR

!

ERROR

!

2

F

Slide9

< Outline >Introduction

Software Product LinesDataflow Analysis (recap)Dataflow Analyses for Software Product Lines:

feature in-sensitive (A1) vs feature sensitive

(A2, A3, A4)Results:A1 vs A2 vs A3 vs

A4 (in theory and practice)Related WorkConclusion

Slide10

Dataflow AnalysisDataf

low Analysis:1) Control-flow graph2) Lattice (finite

height)3) Transfer functions (monotone)

L

Example

:

"

sign-of-

x

analysis

"

Slide11

Analyzing

a Program

1

)

Program

2

)

Build CFG

3

)

Make Equations

4

)

Solve

equations

:

fixed

-point

computation

(

iteration

)

5

)

SOLUTION

(least fixed point)

:

Annotated with program points

Slide12

< Outline >Introduction

Software Product LinesDataflow Analysis (recap)Dataflow Analyses for Software Product Lines:feature in-sensitive

(A1) vs feature sensitive (A2, A3, A4

)Results:A1 vs A2 vs A3 vs A4 (in theory and practice)Related WorkConclusion

Slide13

A1 (brute force)A1 (feature in-

sensitive):N = 2F compilations!void m() { int x=0;

ifdef(A) x++; ifdef(B) x--;}c = {A}:

c = {B}:c = {A,B}:

int x = 0;

x++;

x--;

int

x

= 0;

x++;

x--;

int

x

= 0;

x++;

x--;

0

_

|

+

0

_

|

-

0

_

|

0/+

+

ψ

FM

=

A∨B

L

Slide14

A2 (consecutive)A2 (feature sensitive

!):void m() { int x=0; ifdef(A) x++;

ifdef(B) x--;}c = {A}:c

= {B}:c = {A,B}:

int x = 0;

x++;

x--;

int

x

= 0;

x++;

x--;

int

x

= 0;

x++;

x--;

0

_

|

+

0

_

|

-

0

_

|

0/+

+

A:

B:

A:

B:

A:

B:

0

+

✗

✓

✓

✗

✓

✓

✓

✓

✓

ψ

FM

=

A∨B

L

Slide15

A3 (simultaneous)A3 (feature sensitive

!):void m() { int x=0; ifdef(A) x++;

ifdef(B) x--;}∀c ∈ {{A},{B},{A,B}}:

int x

= 0;

x++;

x--;

0

_

|

+

0

_

|

-

0

_

|

0/+

+

A:

B:

0

+

✓

({A} = , {B}

=

, {A,B} = )

({A} = , {B}

=

, {A,B} = )

({A} = , {B}

=

, {A,B} = )

({A} = , {B}

=

, {A,B} = )

✓

✓

✓

✓

✓

✓

✗

✗

ψ

FM

=

A∨B

L

Slide16

A4 (shared)A4 (feature sensitive

!):void m() { int x=0; ifdef(A) x++;

ifdef(B) x--;}ψFM = A∨B:

int x = 0;

x++;

x--;

A:

B:

_

|

( [[

ψ

]] = )

0

+

( [

[

ψ

∧

¬

A

]] = ,

[[

ψ

∧A

]] = )

0

( [[

ψ

]] = )

(

A∨B)∧

¬

A∧¬B ≡

false

…using

BDD

representation

!

(

compact

+

efficient

)

+

-

0/+

( [

[ψ∧

¬A∧¬B]] = , [[ψ∧A∧¬B]] = , [[ψ∧¬A∧B]] = , [[ψ∧A∧B]] = )

0

i.e.,

invalid

given

wrt

.the feature model,

ψ !

ψFM = A∨B

L

Slide17

Specification: A1, A2, A3,

A4A1

A2A3A4

Slide18

A1, A2, A3, and A4

A1

A2

A3A4

Slide19

< Outline >Introduction

Software Product LinesDataflow Analysis (recap)Dataflow Analyses for Software Product Lines:feature in-sensitive

(A1) vs feature sensitive (A2, A3, A4

)Results:A1 vs A2 vs A3 vs A4 (in theory and practice)Related WorkConclusion

Slide20

Intraprocedural EvaluationFour (qualitatively different)

SPL benchmarks:Implementation: A1, A2, A3, A4 in

SOOT + CIDEEvaluation: total time, analysis time, memory usage

Slide21

Results (total time)In theory:In practice:

6x

8x14x

3x5x3x1x

1x1x2x2½x

2xA2 (3x),

A3 (4x), A4 (5x)

Feature sensitive (avg. gain factor):

(

Reaching Definitions)

2

F

2

F

2

F

Slide22

Results (analysis time)In theory:In practice:

T

IME(A4) : Depends ondegree of sharing in SPL !

(caching!)

(Reaching Definitions)A3 (1.5x) fasterOn average (A2 vs A3):

A2

A3

vs

2

F

Slide23

Results (memory usage)In theory:

In practice:

(

Reaching Definitions)

6.3 : 1

Average

2

F

A2

A3

vs

S

PACE

(

A

4

)

: Depends on

degree of

sharing

in SPL

!

Slide24

< Outline >Introduction

Software Product LinesDataflow Analysis (recap)Dataflow Analyses for Software Product Lines:feature in-sensitive

(A1) vs feature sensitive (A2, A3, A4

)Results:A1 vs A2 vs A3 vs A4 (in theory and practice)Related WorkConclusion

Slide25

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 (~ A3

and 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 1998Our work: Automatically lift any DFA to SPLs (with ψ

FM) ⇒feature-sensitive analysis for analyzing entire program family

Slide26

Related Work (Lifting for SPLs)Model Checking:

Type Checking:Parsing:Testing:

Model Checking Lots of Systems: Efficient Verification of Temporal Properties in Software Product Lines”( Classen, Heymans, Schobbens, Legay, and Raskin )

ICSE 2010Model checks all SPLs at the same time (3.5x faster) than one by one! (similar goal, diff techniques)Type checking ↔ DFA (s

imilar goal, diff techniques)Our: auto lift any DFA (uninit vars, null pointers, ...)“Type Safety for Feature-Oriented Product Lines”

( Apel, Kastner, Grösslinger, and Lengauer ) ASE 2010

“Type-Checking Software Product Lines - A Formal Approach”( Kastner

and Apel ) ASE 2008

“Variability-Aware Parsing

in the

Presence of Lexical Macros & C.C.”

(

Kastner

,

Giarrusso

,

Rendel

,

Erdweg

,

Ostermann

,

and Berger )

OOPSLA 2011

“Reducing

Combinatorics

in Testing Product

Lines”

(

Hwan,

Kim,

Batory, and Khurshid )

AOSD 2011Select relevant feature combinations for a given

test caseUses (hardwired) DFA (w/o FM) to compute reachability(similar techniques, diff goal):Split and merging parsing (~A4) and also uses instrumentation

Slide27

Emerging Interfaces

Slide28

Emerging Interfaces

"A Tool for Improving Maintainability of Preprocessor-based Product Lines"( Márcio

Ribeiro, Társis Tolêdo, Paulo Borba, Claus Brabrand )

*** Best Tool Award ***

CBSoft 2011:

Slide29

< Outline >Introduction

Software Product LinesDataflow Analysis (recap)Dataflow Analyses for Software Product Lines:feature in-sensitive

(A1) vs feature sensitive (A2, A3, A4

)Results:A1 vs A2 vs A3 vs A4 (in theory and practice)Related WorkConclusion

Slide30

Conclusion(s)It is possible

to analyze SPLs using DFAsWe can automatically

"lift" any dataflow analysis and make it feature sensitive:A2

) ConsecutiveA3) SimultaneousA4) Shared SimultaneousA2,A3,A4 much faster (

3x,4x,5x) than naive A1A3 is (1.5x) faster than A2 (caching!)

A4 saves lots of memory vs

A3 (sharing!)

6.3 : 1

Slide31

Future WorkExplore how all

this scales to…:In particular:

…relative speed of A1 vs A2 vs A3 vs A4 ?…which analyses

are feasible vs in-feasible ?INTER-procedural

data-flow analysisIn progress...!

Slide32

< Obrigado* >

*)

Thanks

Slide33

BONUS SLIDES

Slide34

Results (analysis time)In theory:In practice:

T

IME(A4) : Depends ondegree of sharing in SPL !

Nx1 ≠ 1xN

?!(caching!)(Reaching Definitions)

A3 (1.5x) faster

On average (A2 vs A3):

A2

A3

vs

2

F

2

F

Slide35

A2 vs A3 (caching)

Cache misses in A2 vs A3:Normal cache:As expected, A2 incurs more cache misses (⇒ slower!)

Full/no cache*:As hypothesized, this indeed affects A2 more than A3i.e., A3 has better cache properties than A2

*) we flush the L2 cache, by traversing an 8MB “bogus array

” to invalidate cache!A2

A3vs

Slide36

IFDEF normalizationRefactor "undisciplined"

(lexical) ifdefs into "disciplined" (syntactic) ifdefs:Normalize "ifdef"s

(by transformation):

Slide37

Example Bug from LampiroLampiro SPL (IM client for XMPP protocol):

*** uninitialized variable "logo"(if feature "GLIDER" is defined)Similar problems with:

undeclared variables, unused variables, null pointers, ...

Slide38

BDD (Binary Decision Diagram)Compact and efficient

representation forboolean functions (aka., set of set of names)

FAST: negation, conjunction, disjunction, equality !



= 

F

(A,B,

C) =

A(BC)





A

C

minimized BDD

B

















A

B

B

C

C

C

C

BDD

Slide39

Formula ~ Set of ConfigurationsDefinitions (given F

, set of feature names):f  F feature namec  2F configuration

(set of feature names) c  FX  2

2 set of config's (set of set of feature names) X  2F

Exampleifdefs:

F

[[ BA ]]

[[

A(BC)

]]

F

= {A,B}

F

= {A,B,C}

= { {A}, {B}, {A,B} }

= { {A,B}, {A,C}, {A,B,C} }

Slide40

Feature Model (Example)Feature Model:

Feature set:Formula:Set of configurations:



FM  Car  Engine  (1.01.4)  Air1.4 { {Car, Engine,

1.0}, {Car, Engine, 1.4}, {Car, Engine, 1.4, Air

} }

F = {Car,

Engine, 1.0, 1.4,

Air

}

Note

:

|

[[



FM

]]

| =

3

<

32

= |2

F

|

[[

]] =

Engine

1.0

Air

Air

1.4

Slide41

Conditional CompilationThe 'ifdef' construction:Syntactic variant of lexical

#ifdefPropositional Logic: where fF (finite set of feature names)Example:

STM : 'ifdef' '('  ')'

STM  : fF |

 |  status.print("you die"

);ifdef (DeluxeVersion && ColorDisplay

) { player.redraw(Color.red);

Audio.play("crash.wav"

);

}

lives = lives - 1;

A

ifdef

(

A

)

{

...

}

Slide42

Lexical #ifdef  Syntactic ifdef

Simple transformation: We do not handle non-syntactic '#ifdef's:

Fair

assumption(also in CIDE)

Nested ifdef's also give rise to a conj.of formulas

Slide43

CASE 1

: "COPY"A4: Lazy Splitting (using BDDs)

CASE 2: "APPLY"

CASE 3: "SPLIT":

S

[

=l

, ... ]

[



=

l

, ...

]

l '

=

f

S

(

l

)













:

S

[



=

l

, ...

]

[



=

l '

, ...

]

l '

=

fS(l

)



: S

[



=

l , ... ]

[





=

l, =

l' ,...]

l '

= f

S(l

)







 = Ø



 = 

Ø  

 