Analysis of Pointers and Structures

Transcription

1 RETROSPECTIVE: Analysis of Pointers and Structures David Chase, Mark Wegman, and Ken Zadeck Historically our paper was important because it demonstrated that it was possible to get useful information about linked data structures in a practical amount of time. At the time of publication, there was some interest in pointer analysis from the theoretical community, but these algorithms were generally impractical. Our paper presented a technique that combined a clever lattice representation of pointer information with an incremental algorithm for updating SSA (static single assignment form) on the fly. This set the stage for significant work by others because it showed that pointer-related information could be harvested from a program using algorithms that were computationally accessible. Our paper has many rough spots, the worst being our treatment of interprocedural analysis. We had set out to take our ideas on SSA form and expand them to analyze pointer structures. For this, we succeeded pretty well. However, since SSA form had at that time been primarily used for intraprocedural analysis, we almost forgot about the interprocedural impact until very late in the writing of the paper and our treatment is regrettably shallow. In retrospect, the interprocedural issues are more important than the intraprocedural ones and we are fortunate that others followed us. Michael Hind has assembled an excellent overview of work in this field [7, 6]. There were two main problems that we attacked: One was to make practical the time complexity of heap pointer analysis, and the other was gathering information that was likely to be useful about the shape of structures in the heap. Our key insights for improved performance were to modify the SSA algorithm to deal incrementally with newly introduced variables, and to restate costs in terms of the size of the answer. The worst-case costs occur when everything is aliased to everything, which in the intraprocedural case is rare. Doing this allowed us to get polynomial time bounds of a reasonable degree. However, in the interprocedural setting you can get large alias sets, a problem that has been addressed by (for example) Aiken, Fähndrich, Foster, Su [1]. Getting good shape and sharing information required careful attention to the rules for grouping sets of heap nodes. The basic idea of abstracting sets of heap nodes into representatives had been around at least since Muchnick and Jones paper [8]. Essentially, we both treat a group of heap elements as if they were a variable in SSA form. We chose allocation site, variable reference patterns, and inferred heap reference count as attributes that could separate heap elements. This was partly intuitive, and partly what worked. It makes sense that objects from different allocation sites or referenced from different variables might be treated differently. Partitioning on heap reference count (0, 1, many) was intended to cap- 20 Years of the ACM/SIGPLAN Conference on Programming Language Design and Implementation ( ): A Selection, Copyright 2003 ACM $5.00. ture the notion of sharing from things we might not know much about ; it also happened to allow the analysis to dereference objects out of the heap and know that they were not shared. This allowed the inference of strong (killing) updates. Inferring reference counts was not new (similar analyses were described in the SETL compiler and by Jeff Barth [2, 5]) and heap-reference counting has been used in garbage collectors over the years [3]. However, our aim was different, and instead of using reference counting to determine inaccessibility, we used it to determine when objects were not aliased. Sagiv, Reps, and Wilhelm made an important improvement to this in [9]. The paper contains at least one error and one serious omission. The error occurs because the renaming and separation that takes place at some phi-functions can introduce non-monotonicity. This can be fixed by carefully constraining the evaluation order. We had intended to publish a separate paper detailing a more general incremental SSA algorithm based on what we learned writing this paper, but we never finished this. In part this was because we later found a reference to work by Dietz [4] that we did include in our presentations of the work, but hadn t known of in time for the paper itself. Here s a brief outline of how incremental SSA would work and how Dietz s work mostly subsumes it. In ordinary SSA-based algorithms a new name is created for an existing variable at each assignment, and dominated uses refer to the new name. Phi-function assignments are added as necessary to ensure that each use has exactly one definition and that the definition dominates the use. Because of the renaming step, the name is the definition and vice-versa. This works well when the control flow, variables, and definition sites are all known before the SSA transformation. It works less well when new variables and definition sites are discovered as analysis proceeds. In pointer analysis we started assuming that variables and heap locations could contain only pointers to a few locations. As the algorithm proceeds we find they can point to more. Thus we would discover a definition of a new assignment. Our version of incremental SSA still depends upon knowing the control flow in advance (so it is posssible to pre-construct dominance frontiers) but does not perform an explicit renaming of variables. Instead, we regard the dominator tree and the pattern of definitions dominating uses as if it were a context tree [4, 10] of lexical scopes. Just as variable lookup in a lexically scoped language finds the nearest declaration ancestor in the tree of program scopes, definition lookup finds the nearest SSA-definition ancestor in the dominator tree of the control flow graph. We found an efficient solution to this problem, but Dietz s discovery of the same solution preceded ours by eight years and is much more elegant than ours. In closing we d like to comment on where the whole area of ACM SIGPLAN 343 Best of PLDI

2 pointer analysis is likely to find important resonance. Pointer analysis is on the frontier of program analysis and good pointer analysis is likely to be the gating factor in many more advanced analyses. When this paper was written, the goal of program analysis was to speed up the execution of programs. However, many low-level program analysis techniques are becoming less important as the speed of the CPUs grows relative to the speed of memory. Doing a redundant small calculation often doesn t cost anything on today s modern hardware. There are two significant uses of better analysis that were not clear to us at the time the paper was written: 1. While compiler optimization was originally meant to address the point where languages introduced inefficiencies into programs the translation between the language and the assembler code the place inefficiencies are introduced now is in the use of libraries. These libraries are either part of the language or standard components that are reused many times. They may be well-written, but are general, and carry the cost of that generality. Programmer productivity can be enhanced by allowing the programmer to write code without constantly worrying about efficiency. In the past this meant using a high-level language rather than programming in assembly language, but now it means reusing components instead of writing customized software. Optimization can reduce the performance penalty of productive programming by aiding in the selection, combination, and specialization of these components. 2. Helping programmers understand programs is at least as important as helping programs run quickly. The kind of information produced by pointer analysis techniques can be particularly important for debugging or maintaining very large programs. Analysis of this sort can determine a good approximation to the set of uses of a particular data structure as well as the set of locations within a program that can provide values that reach a certain point. Furthermore, the analysis can be done on a demand basis, and can thus supplement documentation which is generally stale. As software becomes larger and more complex, tools based on techniques like ours will continue to grow in importance. ACKNOWLEDGEMENTS About ten years ago, a graduate student in Germany sent us describing how he implemented our algorithm, discovered the renaming non-monotonicity, and how he fixed it. Unfortunately, we lost his name. REFERENCES [1] Alexander Aiken, Manuel Fähndrich, Jeffrey S. Foster, and Zhendong Su. Partial online cycle elimination in inclusion constraint graphs. In ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI 98), June [2] Jeffrey M. Barth. Shifting garbage collection overhead to compile time. Communications of the ACM, 20(7): , July [3] L. Peter Deutsch and Daniel G. Bobrow. An efficient, incremental, automatic garbage collector. Communications of the ACM, 19(9): , September [4] Paul F. Dietz. Maintaining order in a linked list. In Proceedings of the Fourteenth Annual ACM Symposium on Theory of Computing, pages , May [5] Stefan M. Freudenberger, Jacob T. Schwartz, and Micha Sharir. Experience with the SETL optimizer. ACM Transactions on Programming Languages and Systems, 5(1):26 45, January [6] Michael Hind. slides.pdf. PASTE 01 Presentation. [7] Michael Hind. Pointer analysis: Haven t we solved this problem yet? In 2001 ACM SIGPLAN-SIGSOFT Workshop on Program Analysis for Software Tools and Engineering (PASTE 01), June [8] Neil D. Jones and Steven S. Muchnick. Flow analysis and optimization of LISP-like structures. In Steven S. Muchnick and Neil D. Jones, editors, Program Flow Analysis: Theory and Applications, pages Prentice-Hall, [9] Mooly Sagiv, Thomas Reps, and Reinhard Wilhelm. Solving shape-analysis problems in languages with destructive updating. In Conf. Record of the Twenty-Third Annual ACM Symposium on Principles of Programming Languages, January [10] Ben Wegbreit. Faster retrieval from context trees. Communications of the ACM, 19(9): , September ACM SIGPLAN 344 Best of PLDI

3 ACM SIGPLAN 345 Best of PLDI

4 ACM SIGPLAN 346 Best of PLDI

5 ACM SIGPLAN 347 Best of PLDI

6 ACM SIGPLAN 348 Best of PLDI

7 ACM SIGPLAN 349 Best of PLDI

8 ACM SIGPLAN 350 Best of PLDI

9 ACM SIGPLAN 351 Best of PLDI

10 ACM SIGPLAN 352 Best of PLDI

11 ACM SIGPLAN 353 Best of PLDI

12 ACM SIGPLAN 354 Best of PLDI

13 ACM SIGPLAN 355 Best of PLDI

14 ACM SIGPLAN 356 Best of PLDI

15 ACM SIGPLAN 357 Best of PLDI

16 ACM SIGPLAN 358 Best of PLDI

17 ACM SIGPLAN 359 Best of PLDI