Specialization Tools and Techniques for Systematic Optimization of System Software

1. Specialization Tools and Techniques for Systematic Optimization of System Software McNamee, Walpole, Pu, Cowan, Krasic, Goel, Wagle, Consel, Muller, Marlet Presented by: Jesus Morales

2. Introduction • The Problem • Operating Systems design dilemma: • Flexibility vs. • Performance • Common approach • general purpose code optimized for a few anticipated common cases

3. Possible solutions • Explicit customization • OS customized for currently observed common conditions • Ability to customized in OS • Customized code manually written and injected • Code expansion • Inferred customization

4. Specialization • This paper’s approach: inferred customization based on specialization • Create optimized code for the common cases • Restricting vs. extending code • Specialization Toolkit • Purpose: Reduce manual labor • Tools: Tempo, TypeGuard, MemGuard, Replugger

5. Specialization Overview • Concepts • Specialization predicates • Partial evaluation • Residualization • Main design issues • Correctness • Performance

6. Specialization Overview (cont.) • Three kinds of specialization • Static • Specialization predicates known at compile time • Partial evaluation applied before system execution • Dynamic • Run-time specialization • Predicates established at some point during execution • Once established, predicates hold • Optimistic • Predicates only hold for bounded intervals

7. Specialization Steps • System tuner takes the following steps: • Identify specialization predicates • Lots of coffee and tea. • Generate specialized code • Tempo: partial evaluator. Generates specialized code. • Check when specialization predicates hold • TypeGuard, MemGuard: locate code that may modify specialization predicates • Replace specialized code • Replugger: safe replacement of specialized code in the face of concurrent execution

8. Tempo • A partial evaluator for C programs • Binding-time analysis: separate static from dynamic parts • Challenges • Pointers and aliases • Structures and arrays • Functions with side-effects

9. Enabling and Disabling Specialized Code: TypeGuard and MemGuard • Specialized code is only correct when specialization predicates hold • Important for dynamic and optimistic specialization • Binding phases • Explicit • Implicit • Tools: TypeGuard and MemGuard

10. TypeGuard • Place guards at the site of modifications to specialization predicate terms • Non-trivial problem: Aliases, structures instances, pointers • Two-phase approach: • First Phase: Static analysis: • identify struct types whose fields are specialization predicate terms • Create Specialization predicate ID (SPID) • Flag operations that create aliases to structure types • Second Phase: dynamically set SPID field when specialized code is enabled

11. MemGuard • Problem: Type-based guarding tool cannot guarantee complete coverage if the language is not type safe (C) • Solution: memory protection hardware • Write-protect pages containing specialization predicate terms • High overhead: use for debugging, not production

12. Replugger: dynamic function replacement • Replace current code when: • Dynamic specialization predicate is established • Optimistic specialization predicate is violated • Asymmetric synchronization: low invocation overhead – higher replugging overhead • Replugging mechanism design factors • Concurrent invocation • Concurrency between replugging and invocation • Counting vs. boolean replugger

13. Specialization Experiment: BSD Packet Filters • Static or dynamic specialization • Case of complex specialization: • Specializing the packet filter interpreter • Specialization predicate: packet filter program • Relation to extensibility • Packet program filters are downloaded into the kernel • Raises security issues

14. while(true) { switch (pc->opcode) { case LD: // do load instruction case JGT: if (accumulator > index_register) pc = pc->target_true else pc = pc->target_false // etc... case RET: // return instruction result =... break; } pc++ } Fig. 8. Basic loop for BPF interpreter. case JGT: if (accumulator > index_register) return(bpf_filter(pc->target_true, c, wirelen, buflen)) else return(bpf_filter(pc->target_false, c, wirelen, buflen)) Fig. 9. Using recursion to make pc static. Specialization Experiment: BSD Packet Filters (cont.)

15. Specialization Experiment: BSD Packet Filters (cont. 2) • Results: • Filter 10 megabytes of ethernet packets

16. Static Specialization: Sun RPC’s Marshalling Stubs

17. Optimistic Specialization: Unix Signals

18. Lessons for System Tuners and System Designers • System Tuners • Session-oriented operations • Domain-specific language interpreters or compilers • System Designers • Explicit relationships between components • Be able to recognize interconnections from repeated patterns of actions

19. Conclusions • Automatic specialization eases the burden on the system tuner: less error prone • Specializations based on the source code: • Less complex • Modular • Maintainable • Speed ups from 15% to 93%

20. This is The End Thanks!