1. Chess Review May 8, 2003 Berkeley, CA Compiler Support for Multithreaded Software Jeremy ConditRob von Behren Feng ZhouEric Brewer George Necula

2. Chess Review, May 8, 2003 2 Designing Concurrent Systems The great debate: threads vs. events Thread model –Each logically concurrent task is represented by a thread –Modules communicate via call/return –Each thread gets its own stack Event model –Each logically concurrent task is represented by an event –Modules communicate via event passing –Event handlers unwind stack after each event

3. Chess Review, May 8, 2003 3 Conventional Wisdom Recent research favors event-based model –Event handlers execute atomically –Lower overhead for managing state –Better scheduling and locality –More flexible control flow –TinyOS, SEDA, Flash, … We argue that all of these benefits can be achieved in thread-based systems –Thread systems and event systems are duals –Duality proposed by Lauer and Needham in 1978 (message passing vs. process-based systems)

4. Chess Review, May 8, 2003 4 The Stack Problem How do we limit stack space? –Event systems: stacks are empty at end of handler –Thread systems: stacks can be arbitrarily large at (or between) blocking points Old solution: preallocate large stacks –Inappropriate when memory available to each thread is limited New solution: linked stack frames –This talk!

5. Chess Review, May 8, 2003 5 Linked Stack Goals Limit amount of preallocated memory Enable stacks of arbitrary size –Recursive functions –Temporary buffers –Short-lived “spikes” in stack size Provide development tools –Existing debuggers –Profiling tools to tune stack allocation

6. Chess Review, May 8, 2003 6 Our Options preallocated whole stack never preallocate small chunks

7. Chess Review, May 8, 2003 7 Instrumenting Call Sites Add instrumentation to some call sites –Check for sufficient stack space –Allocate and link new chunk if necessary How much space is sufficient? –Largest amount of stack space used until another instrumented call site is reached How do we get this information? –Analyze call graph at compile time –Dynamic programming –Instrumenting call site $ removing graph edge

8. Chess Review, May 8, 2003 8 Call Graph Analysis Input: –Call graph –MaxPath parameter Output: –Set of edges to instrument –Stack bound for each node 1.Instrument all back edges 2.Process each node in call graph, bottom-up 1.For each successor 1.Let bound = successor’s bound + current node’s stack 2.If bound > MaxPath, instrument edge 2.Set node’s stack bound

9. Chess Review, May 8, 2003 9 Call Graph Example 5k 8k 1k2k 1k 10k 4k 9k MaxPath = 10k

10. Chess Review, May 8, 2003 10 Wasted Space Two kinds of wasted space: –Internal: unused space at the end of interior chunks –External: unused space at the end of the final chunk

11. Chess Review, May 8, 2003 11 Tuning Two parameters: –MaxPath: maximum desired path length –MinChunk: minimum allowable chunk size Tradeoffs: amount of instrumentation internal wasted space external wasted space MaxPathMinChunk

12. Chess Review, May 8, 2003 12 Results: Apache 2.0.44 MaxPath = 4 KB, MinChunk = 8 KB Compile-time statistics –7500 call sites –17% instrumented external calls –5% instrumented internal calls Run-time statistics (one request) –1300 function calls –25% instrumented external calls instrumentation can be eliminated in 95% of cases –8% instrumented internal calls new chunk linked in 25% of cases –1000 instructions per request

13. Chess Review, May 8, 2003 13 Conclusions Threads and events are duals –With proper compiler support, threads can perform just as well as events –Threads provide a more appropriate abstraction for many concurrent applications Linked stacks can reduce stack waste –One example of compiler support for threads