A staged - PowerPoint Presentation

Slide1

A stagedstatic program analysis toimprove the performanceof runtime monitoring

Eric BoddenLaurie HendrenOndrej Lhotak

McGill University

University of WaterlooSlide2

Tale of the industry programmer

2Uses 3rd party code with many architectural constraintsHas no time to read all documentationWrites large programswith many dependencies

Suffers from bugsSlide3

A typical bug patternTaken from java.util.Collections

Collection syncC = Collections.synchronizedCollection(myC); synchronized(syncC) {

}

Iterator

i

=

syncC.iterator

();

while

(i.hasNext()) foo(i.next());

3Slide4

Tracematch "ASyncIteration"tracematch

(Collection c) { sym sync after returning(c): call(* Collections.synchronizedCollection(..)); sym asyncIter around: call(* Collection+.iterator()) && target(c) && if(!Thread.holdsLock(c)); sync asyncIter { //logging or recovery code synchronized(

c) { proceed(c);

}

}}

4Slide5

Evaluation through automaton5

syncasyncIter

sync

asyncIter

skip(

asyncIter

)

No skip-loops in this talk!Slide6

Shadows, bindings and skip loops

Collection myC = new ArrayList(); Collection syncC = Collections.synchronizedCollection(myC); Iterator i = syncC.iterator(); 6

sync

aSyncIter

c=

syncC

c=

syncC

Oxford

Leak elimination/

Indexing

[

ATdM

07]

Us!

trueSlide7

This talk: remove overhead through static program analysis

7Program safe!Slide8

Staged analysisremove as many shadows, as early as possible

8Slide9

Quick check

For a complete match, need to see all necessary symbols.Hence, remove entire tracematches where not all necessary symbols match.9QuickSlide10

Quick check - example

syncaSyncIter10

QuickSlide11

Flow-insensitive analysisFor a complete match, need to see all necessary symbols

with a consistent variable bindingRemove groups of shadows for which a consistent variable binding is impossible to achieveExample: even if a program uses synchronized collections, most collections will never be synchronized11Flow-ins.Slide12

Flow-insensitive analysisFirst have to determine which shadows are

required for a complete match12Flow-ins.Slide13

register

notifynotify

Example – observer pattern

register notify

*

notify

Resulting state machine has no cycles,

can enumerate all paths.

Flow-ins

.

13Slide14

register

notify[register,

notify]

“path info”

Flow-ins

.

Example – observer pattern

14Slide15

Flow-insensitive analysisEach path info represents a single complete path to a final stateNow for each path info

find corresponding consistent groups of shadowsconsistent = can potentially refer to the same objects at every shadow in the groupUses points-to setsFlow-ins.15Slide16

c1

c2[sync,aSyncIter]{s1} {a1,a2}x{s1, a1}

{s1, a

2

}

for this path-info keep s

1

, a

1

Flow-ins

.

16

“complete & consistent shadow group”new LinkedList();Slide17

Preparation phaseright before the flow-insensitive stagebuilds context-sensitive points-to sets

demand-driven refinement-based analysisby Sridharan and Bodik [SB 06]as a side effect builds a call graph (which can then be used in flow-sensitive stage)relatively expensivecan increase compile time by a few minutesas of yet, no way to get around itflow-insensitive analysis then usually runs within secondsFlow-ins.17Slide18

Flow-sensitive analysisfor a complete match, need to see all necessary symbols with a consistent variable binding

in the right orderremove groups of shadows for which the shadows can never execute in the order induced by the regular expressionFlow-sens.18Slide19

Flow-sensitive analysisBuild a state machine-like abstraction for each methodCombine abstractions interprocedurally to one large FSM

Build thread information to be thread-safePerform abstract interpretation of tracematch automaton over the whole-program state machineFlow-sens.19Slide20

Flow-sensitive analysisDid not lead to additional improvements

Reasons:Insufficiently precise model of control flow, caused by context-insensitive call graphLack of must-alias information (for skip-loops)Presence of threadsYet, the abstraction we used is very useful, reused large parts of it in later workFlow-sens.20Slide21

BenchmarksTested a number of different tracematches

ASyncIterationHasNextElemFailSafeEnumLeakingSyncFailSafeIterReaderHashMap

Writer

HasNext

21Slide22

Benchmarks... on the entire DaCapo suite

antlrhsqldbbloatjythonchartluceneeclipse

pmd

fop

xalan

22Slide23

Slowdowns before opt.

ASyncIterationFailSafeEnumFailSafeIterHashMapHasNextElemHasNextLeakingSyncReaderWriterantlr

1.07x

9.78x

1.41x

bloat

1.35x

Some

hrs.

1.34x

14.83x

2.36x

1.32xchart1.08x1.88x

eclipse

1.03x

1.05x

fop

1.04x

2.56x

hsqldb

1.04x

jython

1.04x

1.03x

lucene

1.16x

1.13x

1.07x

2.82x

1.54x

pmd

2.12x

1.62x

1.10x

1.06x

1.04x

xalan

slowdown >= 10%

(updated)

23Slide24

Shadow removalFocus on 17 cases with slowdown > 10%Quick check removed all shadows in 6 of those cases

Flow-insensitive stageremoved all shadows for lucene/LeakingSync and lucene/Readersignificant shadow removal for 5 other benchmarksFlow-sensitive stage brought no improvements at allProgram safe!Program safe!24Slide25

aborted

[abc-2007-3]

10x

hours

15x

25

must-alias

imprecisionSlide26

Related workTypestates

Fink et al., ISSTA ‘06: “Effective typestate verification in the presence of aliasing"Only have one free variableMakes flow-sensitive analysis easier [abc-2007-3]Completely static, false positives remainPQLMartin et al., OOPSLA ’05: “Finding Application Errors and Security Flaws Using PQL" Uses similar flow-insensitive analysis, yielding similar speedupsNo quick checkNo flow-sensitive analysis26Slide27

ConclusionsStatic program analysis can often improve the runtime performance of finite state monitors a lotCan even prove many programs sound

Not possible with plain AspectJPrecise points-to information is crucialFlow-sensitive analysis needs to be designed differently [abc-2007-3]27Slide28

Thank youDownload our abc compiler and our papers, examples and benchmarks at:

www.aspectbench.org[abc-2007-3] Eric Bodden, Patrick Lam, Laurie Hendren: Flow-sensitive static optimizations for runtime monitors. abc Technical Report number abc-2007-3, www.aspectbench.org under submission at POPL ‘08[ATdM 07] Pavel Avgustinov, Julian Tibble, Oege de Moor: Making Trace Monitors Feasible. To appear at OOPSLA 2007.

[SB 06] Manu Sridharan, Rastislav Bodik:

Refinement-Based Context-Sensitive Points-To Analysis for Java

. PLDI 2006.

Now part of Soot/abc!

28Slide29

next

nextskip<hasNext>

HasNext – need for Must-alias info

“next next” over {hasNext, next}

29

while(

i

.hasNext())

o =

i

.next();Slide30

Quick check - idea

FailSafeIterASyncIterASyncIterlibrary-tracematchesFailSafeIterASyncIterProgram 1client programs

company rules

domain specific rules

generic API rules

…

not all the tracematches apply to all the programs

30Slide31

Shadows and points-to sets

asyncIter

(c=s2)

asyncIter

(c=s3)

sync(c=s1)

c1

c2

new

LinkedList

();

Flow-ins

.

31Slide32

Flow-insensitive analysisUsually runs within seconds.in addition to the points-to analysis as mentioned previously

Precision depends heavily on the precision of the underlying points-to analysis.Need context information for factory methods (e.g. when binding iterators).Flow-ins.32Slide33

Flow-sensitive analysis - example

sync(c=c3)

aSyncIter(c=c1)

aSyncIter(c=c4)

sync(c=c4)

Step 1 - Model construction

33Slide34

sync(c=c3)

aSyncIter(c=c1)

aSyncIter(c=c4)

sync(c=c4)

34Slide35

1-3

2-3Context-sensitivityvoid foo(HashSet h) { Iterator i = h.iterator(); //1}void bar(HashSet h) { Iterator i = h.iterator(); //2}class HashSet { Iterator iterator() { return new Iterator(); //3 }}353

33Slide36

Flow-sensitive analysisChallenges

need to model multithreading soundlyperformance: it can take a long time to reach the fixed point in generalmany possible combinations of shadows (arrows) and bindings (diamonds)if points-to sets overlap a lot, disjuncts “travel long distances”, history components grow36Slide37

Factors that should be addressedmust-alias information for HasNext(Elem)context-sensitive abstraction

more precise handling of multi-threadingprecision of points-to sets37Slide38

Future workhandle HasNext(Elem) patterns through must-alias information

Nomair Naeem, now at Waterloomore lightweight but focused checkers for hot shadowsmore finegrained handling of threads"may happen in parallel" analysis, Lin Licollaborative runtime verification [RV 07]38Slide39

Tainted stringString

unameAndPw = conn.get();String split[] = unameAndPw.split(“ “);String uname = split[0];String pw = split[1];login(uname, pw);Do not call login with a tainted argument .39