Phase-Based Program Sampling Using Phoenix Chandra Krintz University of California, Santa Barbara Microsoft Faculty Summit July, 2005

Microsoft Faculty Summit, July Problem Statement Software is deployed Poorly optimized With bugs Minimally tested Goal of our work Efficient and accurate profiling of deployed software  Remote profiling  Include users in the process -- transparently To enable more effective software evolution  Couple dynamic compilation and software updating  Collect execution behavior to improve coverage testing Increasingly complex For a wide-range of devices

Microsoft Faculty Summit, July Problem Statement Software is deployed Poorly optimized With bugs Minimally tested Goal of our work Efficient and accurate profiling  Remote profiling  Include users in the process -- transparently To enable more effective software evolution  Couple dynamic compilation and software updating  Collect execution behavior to improve coverage testing Increasingly complex For a wide-range of devices

Microsoft Faculty Summit, July Our Phoenix-Based Research Efficient, flexible, and accurate profile collection Avoid computation/communication interruption Gather important profile types (paths, data, methods…) Our extensions to Phoenix: 1. Turn profiling on and off dynamically Program execution sampling 2. Trigger sampling to enable Highly accurate profiles (similar to exhaustive profiles) With very low overhead (sample very seldomly)

Microsoft Faculty Summit, July Toggling Profile Collection When to sample the executing program Periodically Randomly According to program behavior

Microsoft Faculty Summit, July Toggling Profile Collection When to sample the executing program According to program behavior Method entry Method call

Microsoft Faculty Summit, July Sample According to Program Behavior Duplicate code One copy is instrumented, one is not Alternate execution between them [Arnold’01] Method entry Method entry Method call

Microsoft Faculty Summit, July Toggling Profile Collection Duplicate code One copy is instrumented, one is not Alternate execution between them Method entry Method entry Threshold-based counters Method call

Microsoft Faculty Summit, July Toggling Profile Collection Duplicate code One copy is instrumented, one is not Alternate execution between them Method entry Method entry Method call Control transfers to uninstrumented code Control transfers to instrumented code

Microsoft Faculty Summit, July Toggling Profile Collection Duplicate code One copy is instrumented, one is not Alternate execution between them Method entry Method entry Method call Control transfers to uninstrumented code Control transfers to instrumented code Can also stay in instrumented code for longer periods of time (based on thresholds), i.e., bursts [Hirzel’01,Chilimbi’04]

Microsoft Faculty Summit, July Toggling Profile Collection Phoenix implementation Duplicate code within the same method [Arnold’01] Insert instrumentation in one copy Insert branches that jump between the two  Based on counters Users can Specify the type of profile to collect Threshold values  Global or local  Control sampling frequency and burst length

Microsoft Faculty Summit, July Toggle Triggers Currently, based on counters However, this may cause us to collect redundant information or miss important activities Our second focus is an intelligent sampling trigger Based on program phases [Sherwood’03]  Repeating patterns in program behavior

Microsoft Faculty Summit, July Toggle Triggers Currently, based on counters However, this may cause us to collect redundant information or miss important activities Our second focus is an intelligent sampling trigger Based on program phases [Sherwood’03]  Repeating patterns in program behavior

Microsoft Faculty Summit, July Toggle Triggers Currently, based on counters However, this may cause us to collect redundant information or miss important activities Extant approaches to sampling: Periodic sampling

Microsoft Faculty Summit, July Toggle Triggers Currently, based on counters However, this may cause us to collect redundant information or miss important activities Extant approaches to sampling: Random sampling

Microsoft Faculty Summit, July Toggle Triggers Currently, based on counters However, this may cause us to collect redundant information or miss important activities Extant approaches to sampling: Bursty sampling

Microsoft Faculty Summit, July Toggle Triggers Currently, based on counters However, this may cause us to collect redundant information or miss important activities Our second focus is an intelligent sampling trigger Based on program phases [Nagpurkar’05] Phase-base sampling 5% Error = 55-80% impr.

Microsoft Faculty Summit, July Efficacy of Phase Profiling % sampled vs average error across benchmarks Error = difference between sampled profile and exhaustive profile At 5% error: equates to a 55-80% reduction in overhead % Program Sampled % Error in Block Counts avg random max random periodic phaseaware

Microsoft Faculty Summit, July Conclusions Phoenix provides a framework for program instrumentation, analysis, and optimization Our work Extends Phoenix to enable program sampling  That is parameterizable (frequency, burst length)  Parameters can be changed dynamically Extends sampling to be aware of program behavior  Phase-aware  Enables collection of accurate profiles with very little overhead  55-80% overhead reduction over periodic/random sampling Provides a visualization tool (consumes phase profiles)  Enables users to visualize/reason about program phase behavior

Microsoft Faculty Summit, July Acknowledgements Students involved DirectlyIndirectly Lingli Zhang (prof-guided opt) Sunil Soman (garbage collection) Ricky Tiang (profiling)Hussam Mousa (profile toggling) Priya Nagpurkar (phase profiling)Selim Gurun (embedded systems) Thanks! More Info: Microsoft UCSB RACELab John Lefor Vinod Grover Phoenix Development Team