Dataflow Analysis for Concurrent Programs using Datarace Detection Ravi Chugh, Jan W. Voung, Ranjit Jhala, Sorin Lerner LBA Reading Group Michelle Goodstein 6/5/08

Outline Motivation Overview of Radar Radar Formalization Radar Optimizations Radar(Relay) Evaluation & Results Conclusions

Motivation Want to apply dataflow analysis to concurrent programs without: Requiring annotations Escape analysis (loss of precision) Custom concurrency analysis Model checking (combinatorial explosion)

Introducing Radar Scheme for concurrent dataflow analysis Starts with sequential dataflow analysis Race detection creates concurrent analysis Can use already-created race detectors We’ll see it applied to Relay

Outline Motivation Overview of Radar Radar Formalization Radar Optimizations Radar(Relay) Evaluation & Results Conclusions

Assumptions For each procedure, either Have access to code Have access to a sound summary Shared memory is sequentially consistent

Radar’s Key Insights Adjustability of sequential analysis: Concurrent dataflow facts are a subset of sequential dataflow facts “Missing facts” Facts that can be killed by other threads Suppose we have a fact about lvalue l  “At line y, l is not null” Enough to know if another thread can write to l concurrently  “At line z, another thread can write to l”

Radar’s Key Insights Pseudo-Races : Identify “missing facts”, Remove from sequential analysis Solution: insert a pseudo-read for location l Ask a race detector: “is there a race at this point for l?” Yes  Another thread can write. Remove fact No  No other thread can write. Retain fact. Producer/Consumer examples follow Non-null dataflow analysis Sequential analysis on left Facts “killed” by concurrency crossed out in red

First example: non-null facts Producer–Consumer Pseudo-read for px->data at line PA Consumer thread can execute line C5  Race! px->data is crossed out at line PA

Second example: non-null facts Modified producer/consumer Still race-free, other than perf_ctr Now, producer acquires/releases lock twice

Second example: non-null facts Insert pseudo-read at P5 on px- >data Races with C5 write to cx->data Kills px->data at P5 and where it propagates At P8, not necessarily true that px->data is non-null Null pointer dereference! Note: no data races (except on perf_ctr) We can detect this!

Outline Motivation Overview of Radar Radar Formalization Radar Optimizations Radar(Relay) Evaluation & Results Conclusions

Sequential Dataflow Analysis Representation: nodes in CFG Flow function F(n,d,p): facts true after point p n: node, d: incoming dataflow fact, p: program point lvals(f): lvalues fact f depends on ThreadKill(p,l): computes whether race can occur on l at program point p F adj (n,d,p) = {  f  F(n,d,p),  l  lvals(f), f  ThreadKill(p,l)}

Is Radar Sound? Suppose there is an oracle function O Give a program point p and a location l Returns whether a race is possible Suppose radar is given a race detector R Radar is sound if O(p,l) implies R(p,l) If there is a race, radar wil detect it Can also return false positives

Outline Motivation Overview of Radar Radar Formalization Radar Optimizations Radar(Relay) Evaluation & Results Conclusions

Radar Optimizations Reduce number of times call ThreadKill Handle function calls

Reduce ThreadKill calls Race detector for cross product of program points and lvalues is expensive Many program points have similar behavior For each lvalue in a region: Racy for entire region Not racy for entire region Compute once for entire region Region Map: points  “regions

Incorporating Function Calls To handle function calls: Introduce a new kind of region: Introprocedural Summary Region (SumReg) At a particular call site, approximately summarizes possible regions can pass through To maintain soundness Suppose there is a transitively reachable path from a callsite cs to a racy region Summary region must repot that cs is racy

Radar’s Requirements Race Detection Engine Region  Lvalue  raciness Region Map Points  Race-equivalent Regions Summary Region Map Callsites  Summary Regions

Outline Motivation Overview of Radar Radar Formalization Radar Optimizations Radar(Relay) Evaluation & Results Conclusions

Relay Static race detection tool Lockset-based Works bottom up Scales to the linux kernel

Relay Uses relative lockset analysis: L +, L - : L + : locks definitely acquired since function entry point L - : locks possibly released since function entry point Relative lockset for exit point of function is stored as summary of function’s behavior Approximates effect of function call on locks currently held

Radar(Relay) Race Detection Engine Relay Region Map Maps program point  (g, (L +,L - )) g: function name (L +,L - ): relative lockset summary for function g Summary Region Map Function g being called at the call site cs in function h Computes AllUnlocks(cs) =  L - in g Suppose Region is (h, (L +,L - )) Returns (h, (L + - AllUnlocks(cs),L -  AllUnlocks(cs)))

Pseudoreads Suppose at some program point p fact f holds RegionMap(p): region (g, (L +,L - )) For all lvalues l  lvals(f): Pretend to read l at p with relative lockset (L +,L - ) For any other lvalue m which might be aliased… Intersection of positive locksets is empty  report race

Relay with Radar: Implementation First Pass: Run Relay Computes relative lockset associated with each function Second Pass: Sequential Analysis Pretend no races exist Collect all the possible queries about races Third Pass: Run Relay, Adding Pseudo-reads Insert pseudo-access wherever race query exist Fourth Pass: Adjusted Sequential Analysis At each pseudo-access for l, query race detector If race could occur, kill facts depending on l

Outline Motivation Overview of Radar Radar(Relay) Radar Formalization Radar Optimizations Evaluation & Results Conclusions

Evaluation Focus on non-null dataflow analysis Used 4 black boxes to answer race queries Steensgaard’s pointer analysis If a value is reachable from a global  true Radar alias Region map always returns empty lockset Answers the question of whether any two values alias Radar Optimistic Always return false Unsound, and overly precise

Results

Terminology Blob nodes: Many lvalues on the heap are merged into one node by alias analysis Can lead to false positives when checking null- dereferences Other work shows hard to account for heap structures Next figure excludes “blob nodes” for pointer dereferences Non-blob dereferences: Apache: 52% SSL: 76% Linux: 71%

Results

Consider gap between Seq and Steensgaard Check how much is bridged by Radar With and without locks

Outline Motivation Overview of Radar Radar(Relay) Radar Formalization Radar Optimizations Evaluation & Results Conclusions

Radar is Scalable Not tied to particular concurrency models Tunable to desired precision Radar(Relay) Good precision relative to sequential, steensgaard Future Work More types of analysis Race detection for other concurrency constructs