1. Butterfly Analysis 1  Michelle Goodstein Butterfly Analysis: Adapting Dataflow Analysis to Dynamic Parallel Monitoring Michelle L. Goodstein*, Evangelos Vlachos*, Shimin Chen †, Phillip B. Gibbons †, Michael A. Kozuch † and Todd C. Mowry* *Carnegie Mellon University † Intel Labs Pittsburgh

2. Butterfly Analysis 2  Michelle Goodstein Cannot statically catch all bugs Catching Bugs: Case For Dynamic Program Monitoring Static Analysis: Compilers, formal verification, etc. Dynamic Analysis: Lifeguards: DBI (e.g.,PIN, Valgrind), LBA, DISE We will focus on dynamic analysis via lifeguards Before ExecutionDuring ExecutionAfter Crash Do not want to wait for crash Post-Mortem Analysis: FDR, DeLorean, Strata, BugNet, etc. Before ExecutionDuring ExecutionAfter Crash Motivation: Catch software bugs before they cause serious harm

3. Butterfly Analysis 3  Michelle Goodstein. ld 0x14. st 0x10. Dynamic Program Monitoring Application is dynamically monitored by a lifeguard as it runs –Monitors each dynamic instruction Lifeguard maintains finite-state machine model of correct execution –Checks metadata to see if program does something wrong Ex: Has memory location 0x14 been allocated? Lifeguard Did app malloc 0x14 ? Check metadata Application 0x10 1 0x14 0 0x18. 0x22. Metadata: Allocated? Time ERROR: 0x14 unallocated

4. Butterfly Analysis 4  Michelle Goodstein p=malloc. *p=…. Dynamically Monitoring Parallel Programs Updating metadata straightforward for sequential programs Parallel apps: inter-thread data dependences complicate lifeguards One solution: Timeslice all application threads on one core +State of the art, only requires sequential lifeguard - Slow, serializes application Thread 1 Time. p=NULL. Thread 2 Lifeguard. p=NULL. p=malloc. *p=…. Timesliced App Lifeguard 2Lifeguard 1

5. Butterfly Analysis 5  Michelle Goodstein p=malloc. *p=…. Dynamically Monitoring Parallel Programs Updating metadata straightforward for sequential programs Parallel apps: inter-thread data dependences complicate lifeguards ParaLog: Expose inter-thread data-dependences to lifeguard +Parallel lifeguards for parallel applications -Specialized hardware -Requires sequential consistency or total store order Thread 1 Time. p=NULL. Thread 2 Lifeguard 1Lifeguard 2

6. Butterfly Analysis 6  Michelle Goodstein p=malloc. *p=…. Time. p=NULL. A Counter-Intuitive Proposal Intuition: Lifeguard should process application’s instructions in same order application retires instructions Counter-intuitive: Proceed without capturing inter-thread data dependences –Cannot measure using today’s hardware –Relaxed memory consistency models: no total order Our approach: explicit windows of uncertainty –Outside the window: ordering is known –Ordering unknown within window  Only have a partial order of application instructions  Analysis is conservative (assumes worst case)

7. Butterfly Analysis 7  Michelle Goodstein Handling Uncertainty Only consider a window W of uncertainty How big is the window? Must account for buffering in pipeline and memory system Our experiments: 1000s-10,000s of instructions/thread Window is large relative to ROB, memory access latency Window is small relative to total execution Time. p=NULL. p=malloc. *p=…. W

8. Butterfly Analysis 8  Michelle Goodstein Concept: dynamically cut across all threads –Divide execution into epochs Cuts need only be roughly aligned: incorporate “stagger” time S Can be done in software, using a token ring/fence—no special hardware required! Butterfly Analysis: Bounding Uncertainty...................... p=malloc. *p=…. p=NULL. Thread 1 Thread 2 Thread 3 Time Epoch ≥W≥W Not a barrier ≥W≥W S

9. Butterfly Analysis 9  Michelle Goodstein Epochs: Reasoning About Concurrency From the perspective of the blue epoch Most epochs are non-adjacent –Instructions in these epochs execute strictly before or strictly after Two epochs are adjacent to blue epoch 3 epoch window of potentially concurrent instructions Time Sliding window limited to 3 epochs W Relative To Center Epoch W

10. Butterfly Analysis 10  Michelle Goodstein Next Current Prior Concurrency Within Three Epoch Window Epochs l l-1 l+1 Thread t Concurrent Time

11. Butterfly Analysis 11  Michelle Goodstein Anatomy of a Butterfly Head Tail Body Epochs l l-1 l+1 Thread t Wings Time

12. Butterfly Analysis 12  Michelle Goodstein Butterfly Analysis: Avoiding Potential Pitfalls Combinatorial explosion of potential interleavings –Enumerating all possible interleavings takes too long Lifeguard writer should not need to worry about application ordering Inspiration: Interval analysis handles similar problem Head Tail Body Epochs l l-1 l+1 Thread t Wings Time

13. Butterfly Analysis 13  Michelle Goodstein Brief Review: Interval Analysis B1 B2 B3 B4 B3 Want to compute closure F*(B3) Basic Control Flow Graph F(B3) B3a F*(B3)

14. Butterfly Analysis 14  Michelle Goodstein Interval Analysis vs. Butterfly Analysis Head Tail Body Epochs l l-1 l+1 Thread t Wings B1 B2B3 B4 Interval Analysis: Static analysis on Control Flow Graph Compute closure F*(B3) Only enter top/exit bottom of basic block Specify problem, framework exists to process Butterfly Analysis: Dynamic analysis on execution trace Compute “closure” over wings Enter/exit anywhere due to concurrency Built our own framework Time

15. Butterfly Analysis 15  Michelle Goodstein Butterfly Analysis: Parallel Forward Dataflow Analysis Introduces two new primitives: Side-Out and Side-In –Side-Out: Effects of concurrency a block exposes to other threads –Side-In: Effects of concurrency other threads expose to a block Head Tail Body Epochs l l-1 l+1 Thread t Wings Time

16. Butterfly Analysis 16  Michelle Goodstein Butterfly Analysis: Parallel Dataflow Analysis Introduces two new primitives: Side-Out and Side-In –Side-Out: Effects of concurrency a block exposes to other threads –Side-In: Effects of concurrency other threads expose to a block Head Tail Body Epochs l l-1 l+1 Thread t Wings Time

17. Butterfly Analysis 17  Michelle Goodstein Lifeguard Creation in Butterfly Analysis Lifeguard writer specifies: –Events interested in tracking –Metadata format –Checking algorithm –A meet operation (inspired by dataflow analysis) Lifeguards become 2-pass algorithms (with respect to a butterfly) Example: Reaching (Available) Expressions –Computes whether expression is available across all execution paths –Abstraction for computing properties true on all possible interleavings

18. Butterfly Analysis 18  Michelle Goodstein Simple Example: Reaching Expressions. t=a-b. b=b-1. z=a-b. y=a-b. Thread 1 Thread 2 Thread 3 Time

19. Butterfly Analysis 19  Michelle Goodstein Reaching Expressions Example: Butterfly Analysis t=a-b. z=a-b....... b=b-1......................... y=a-b Time Initial state : a-b available Epochs l l-1 l+1 Thread 1 Thread 2 Thread 3

20. Butterfly Analysis 20  Michelle Goodstein Reaching Expressions Example: Communication After 1 st Pass t=a-b. z=a-b. Thread 1 Thread 2 Thread 3....... b=b-1............. Time Initial state : a-b available. y=a-b After first pass, every block has a Side-Out............ SIDE-OUT l,2 KILL = {} SIDE-OUT l-1,2 KILL = {} Epochs l l-1 l+1 SIDE-OUT l+1,2 KILL = {} SIDE-OUT l,1 KILL = {} SIDE-OUT l-1,1 KILL = {} SIDE-OUT l+1,1 KILL = {a-b} SIDE-OUT l,3 KILL = {} SIDE-OUT l-1,3 KILL = {} SIDE-OUT l+1,3 KILL = {}. b=b-1. SIDE-OUT l+1,1 KILL = {a-b}

21. Butterfly Analysis 21  Michelle Goodstein Reaching Expressions Example: Communication After 1 st Pass t=a-b. z=a-b. Thread 1 Thread 2 Thread 3....... b=b-1............. Time Initial state : a-b available. y=a-b............ Epochs l l-1 l+1 SIDE-OUT l+1,2 KILL = {} SIDE-OUT l,1 KILL = {} SIDE-OUT l-1,1 KILL = {} SIDE-OUT l+1,1 KILL = {a-b} SIDE-OUT l,3 KILL = {} SIDE-OUT l-1,3 KILL = {} SIDE-OUT l+1,3 KILL = {} From perspective of body of the butterfly. y=a-b SIDE-OUT l,2 KILL = {} SIDE-OUT l-1,2 KILL = {}

22. Butterfly Analysis 22  Michelle Goodstein Reaching Expressions Example: Communication After 1 st Pass t=a-b. z=a-b....... b=b-1............. Time Initial state : a-b available. y=a-b Instructions in the head and tail do not interleave with the body............ Thread 1 Thread 2 Thread 3 Epochs l l-1 l+1 SIDE-OUT l,2 KILL = {} SIDE-OUT l-1,2 KILL = {} SIDE-OUT l+1,2 KILL = {} SIDE-OUT l,1 KILL = {} SIDE-OUT l-1,1 KILL = {} SIDE-OUT l+1,1 KILL = {a-b} SIDE-OUT l,3 KILL = {} SIDE-OUT l-1,3 KILL = {} SIDE-OUT l+1,3 KILL = {}

23. Butterfly Analysis 23  Michelle Goodstein Reaching Expressions Example: Communication After 1 st Pass t=a-b. z=a-b....... b=b-1............. Time Initial state : a-b available. y=a-b Body computes the meet of the Side-Out of the wings to get the Side-In Thread 1 Thread 2 Thread 3 Epochs l l-1 l+1 SIDE-OUT l,1 KILL = {} SIDE-OUT l-1,1 KILL = {} SIDE-OUT l+1,1 KILL = {a-b} SIDE-OUT l,3 KILL = {} SIDE-OUT l-1,3 KILL = {} SIDE-OUT l+1,3 KILL = {} meet SIDE-IN l,2 KILL = { a-b } Defined in paper; not standard reaching exps meet

24. Butterfly Analysis 24  Michelle Goodstein Reaching Expressions: 2 nd Pass Initiate 2 nd pass, incorporating Side-In Side-In shows that a-b was not necessarily globally available........ Initial state : a-b available SIDE-IN l,2 KILL = { a-b } y=a-b

25. Butterfly Analysis 25  Michelle Goodstein Butterfly Lifeguards Canonical examples: –Reaching Definitions, Reaching Expressions Lifeguards: – A DDR C HECK, T AINT C HECK In all cases, provably guaranteed zero false negatives –Lifeguard never misses true error Lifeguards may experience false positives due to conservative analysis –Occasionally mistake a safe event for an error Suitable for relaxed memory consistency models –Require respect of intra-thread data dependences, cache coherency See paper for details

26. Butterfly Analysis 26  Michelle Goodstein Butterfly Analysis: A DDR C HECK As Prototype A DDR C HECK, a memory lifeguard –Checks that memory locations are unallocated before a malloc –Checks that memory locations are allocated before free/read/write –Adaptation of Reaching Expressions. ld 0x14. st 0x10. Lifeguard Check metadata Application 0x10 1 0x14 0 0x18. 0x22. Metadata: Allocated? Time ERROR: 0x14 unallocated

27. Butterfly Analysis 27  Michelle Goodstein Experimental Framework Prototype built upon the Log-Based Architecture (LBA) framework –Full butterfly analysis stack implemented in software –Simulated hardware on shared-memory CMP using Simics –Used LBA for dynamic instruction traces, inserting epoch boundaries Measured 3 CMP configurations: 4,8,16 cores –Corresponds to 2,4,8 application and lifeguard threads Measured two epoch sizes: 8K, 64K instructions/thread

28. Butterfly Analysis 28  Michelle Goodstein A DDR C HECK Performance Results 2 app/2 lifeguard threads 4 cores total 4 app/4 lifeguard threads 8 cores total Normalized to sequential, unmonitored 8 app/8 lifeguard threads 16 cores total

29. Butterfly Analysis 29  Michelle Goodstein A DDR C HECK Performance Results Normalized to sequential, unmonitored

30. Butterfly Analysis 30  Michelle Goodstein A DDR C HECK Performance Results Normalized to sequential, unmonitored On average: Butterfly Analysis greatly outperforms TimeslicedButterfly Analysis performs well relative to parallel unmonitored, and much better than Timesliced Butterfly Analysis outperforms Timesliced Room for improvement relative to parallel unmonitored Butterfly Analysis scales well, but small slowdown relative to Timesliced

31. Butterfly Analysis 31  Michelle Goodstein Sensitivity to Epoch Sizes: Performance and False Positives Normalized to sequential, unmonitored Restricting focus to 16 core CMP configuration only (8 app/8 lifeguard threads) Logscale Epoch Size (insts/thread) PerformancePrecisionPerformancePrecision

32. Butterfly Analysis 32  Michelle Goodstein Contributions Butterfly analysis: Framework for dynamic parallel monitoring –Key insight: explicitly model regions of uncertainty –Inspired by interval analysis –New primitives: Side-Out and Side-In Prototype of real lifeguard demonstrates: –Better performance than Timesliced (most cases) –Lifeguards scale well with additional cores –Low false positive rates Epoch size: Trade off performance and accuracy Framework can be applied to tools beyond ones shown here