Component-Level Dataflow Analysis

Atanas (Nasko) Rountev

Ohio State University

CBSE'05

Outline

Interprocedural dataflow analysis

Problem: making dataflow analysis usable

and useful for component-based software

Whole-program analysis: limitations

Technical challenges

Ongoing and future work

CBSE'05

Uses of Dataflow Analysis

Software understanding tools

Software testing

e.g. dataflow-based testing; testing of object

interactions in OO software

Software checking

e.g. dependence analysis for program slicing,

change impact analysis, refactoring, etc.

e.g. object protocols: open(read|write)*close

Performance optimizations in compilers

CBSE'05

Model for Whole-Program Analysis

code for C1
code for C2

code for Cn

Whole
Program
Dataflow
Analysis

dataflow
solution for
C1 + C2 + + Cn

C1 + C2 + + Cn constitute a complete program

Implicit assumption: it is possible and desirable
to analyze the source code of the entire
program as a single unit
CBSE'05

Limitations of Whole-Program Analysis

What if some of the components are only

available in binary form?
What if we are building a library?
What if we are using large libraries that
need to be re-analyzed from scratch?

e.g. the standard Java libraries contain a few

thousand classes

What if one part of program changes?

may have to re-analyze the entire program

CBSE'05

Outline

Interprocedural dataflow analysis

Whole-program analysis: limitations

Problem: making dataflow analysis usable

and useful for component-based software

Dozens of existing analyses could potentially

become useful for component-based software
In tools for software understanding,
testing, checking, and optimization
Technical challenges
CBSE'05

A Simple Case: Main + Lib

code for Lib

code for Main

summary for Lib

Component
Level
Dataflow
Analysis
Component
Level
Dataflow
Analysis

dataflow
solution for Lib
summary for Lib
dataflow
solution for
Main

Goal: the solution for Main should be as good as

the solution that would have been computed by
a whole-program analysis (no loss of precision)
CBSE'05

Component Model and Summary Info

Component = set of related procedures

or classes

Component interactions: synchronous calls,

shared variables

Challenge: more sophisticated component

models
Summary information is computed based
only on the source code of Lib
Challenge: use info from component
specifications
CBSE'05

Summary Functions
Main
Lib

Main calls
procedure Q
Q

path p1: dataflow function f1

path p2: dataflow function f2
CBSE'05

Summary
function for Q:
fQ = f1 f2
computed by
the analysis
of Lib

Open Questions

Challenge: compact representation of

dataflow functions and their transitive
composition and meet

Existing work solves this problem for some

analysis categories; need generalizations

Challenge: callbacks

e.g., function pointers in C

e.g., virtual dispatch in C++ and Java
Fundamental problem, not addressed
adequately by existing work
CBSE'05

10

Callbacks
Main
Lib

Main calls
procedure Q;
during the call,
Lib calls R

R
Q

The function
for p2 cannot be
computed until
Main is analyzed

Solution: summary functions for subpaths,

subpaths
computed during the analysis of Lib;
Later, compose them with the functions from Main
CBSE'05

11

Ongoing Work

Goal 1 (achieved): theoretical model for

computing and using summary functions in
the presence of callbacks
Goal 2 (ongoing): instantiate the model to
common categories of analyses

dependence analysis, pointer analysis, etc.

Goal 3:
3 experimental evaluation

e.g. how large are the summaries?

Eclipse plug-in for call graph construction:
needs summary info for all Java 1.4 libraries
CBSE'05

12

Future Work

Beyond the traditional restrictions

Higher-level of abstraction for

component interfaces and interactions

Use not only code, but also component

specifications: e.g., sharpen the summary
functions based on preconditions

Right now: low-level mechanisms such as

procedure calls and shared variables

Extensive experimental evaluation on

real-world software systems
CBSE'05

13