Phase-Based Program Sampling Using Phoenix

1
Phase-Based Program Sampling Using Phoenix

• Chandra Krintz
• University of California, Santa Barbara
• Microsoft Faculty Summit
• July, 2005

2
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

3
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

4
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
• Turn profiling on and off dynamically
• Program execution sampling
• Trigger sampling to enable
• Highly accurate profiles (similar to exhaustive
  profiles)
• With very low overhead (sample very seldomly)

5
Toggling Profile Collection

• When to sample the executing program
• Periodically
• Randomly
• According to program behavior

6
Toggling Profile Collection

• When to sample the executing program
• According to program behavior

7
Sample According to Program Behavior

• Duplicate code
• One copy is instrumented, one is not
• Alternate execution between them Arnold01

Method entry
8
Toggling Profile Collection

• Duplicate code
• One copy is instrumented, one is not
• Alternate execution between them

Threshold-based counters
Method entry
9
Toggling Profile Collection
Control transfers to uninstrumented code

• Duplicate code
• One copy is instrumented, one is not
• Alternate execution between them

Control transfers to instrumented code
Method entry
Method call
10
Toggling Profile Collection
Control transfers to uninstrumented code

• Duplicate code
• One copy is instrumented, one is not
• Alternate execution between them

Control transfers to instrumented code
Method entry
Can also stay in instrumented code for longer
periods of time (based on thresholds),
i.e., bursts Hirzel01,Chilimbi04
Method call
11
Toggling Profile Collection

• Phoenix implementation
• Duplicate code within the same method Arnold01
• 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

12
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 Sherwood03
• Repeating patterns in program behavior

13
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 Sherwood03
• Repeating patterns in program behavior

14
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
15
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
16
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
17
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
• Nagpurkar05

Phase-base sampling 5 Error 55-80 impr.
18
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

19
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

20
Acknowledgements

• Students involved
• Directly Indirectly
• 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 www.cs.ucsb.edu/racelab
• Vinod Grover
• Phoenix Development Team