Longitudinal program analysis

• Authors: David Notkin
• Venue: Proceedings of the 2002 ACM SIGPLAN-SIGSOFT workshop on Program analysis for software tools and engineering
• Year: 2002

The field of program analysis has made significant improvements recently, but still faces some major obstacles. In this talk I argue that considering analysis as applying longitudinally across the multitude of versions created during a program's lifetime -rather than to a given instance of a program - shows significant promise in overcoming some of these obstacles. I focus on identifying a set of opportunities that arise when this shift in outlook is taken.Most program analysis techniques have focused on questions of the form "Does program P satisfy a given property A?" or "What program points in P satisfy a given property A?" Type-checking is the classic example of the first form, while lexical, syntactic, and semantic analyses are examples of the second form. The key point (with respect to this talk) is that a single program P is being analyzed.Some analyses expand this view and explicitly consider a pair of programs, P and P', where P' represents a modified version of P. Test selection and prioritization techniques are among the best examples of this approach: the idea is to analyze the delta between P and P', and to use that information to determine which test cases must be re-run (for test selection) or should be re-run (for test prioritization). (There are dozens of results in these areas; Harrold et al.'s empirical study is one recent example of test selection [1], and the recent work at Microsoft Research is an example of test prioritization [2].There are at least three ways in which a longitudinal approach could improve analysis.Second, we can use previously computed information to better inform analysis on a newer version. One recent example of this is the work by Kim and Porter that uses historical information about the application of tests of a set of versions as a basis for test prioritization algorithms [3].Third, we can imagine applying otherwise "intractable" analyses over the lifetime of (multiple versions of) a program, as opposed to the (much more limited) time available to analyze a specific version. In essence, there is an opportunity to compute the analysis in stages, with the goal of completing the analysis by specific important points in the program lifetime (e.g., external releases). Work on vertical staging of analyses for runtime compilation is one place to look for ideas and techniques for this kind of "horizontal" staging [4].The traditional view of software evolution says that (to accommodate needed change) program structure degrades and program size increases [5][6]; this in turn tends to increase the difficult of analysis. I propose here some opportunities for viewing time and change as potential benefits with respect to analysis, rather than as roadblocks. This provides potential for significantly improving software dependability over time.