Predicting Runtime Data Dependences for Slice Inspection Prioritization

Transcription

1 Predicting Runtime Data Dependences for Slice Inspection Prioritization Yiji Zhang and Raul Santelices University of Notre Dame Notre Dame, Indiana, USA {yzhang20 Abstract Data dependences are building blocks for techniques such as program slicing and, thus, are useful for program comprehension and debugging. Unfortunately, static analysis identifies many data dependences that are infeasible or unlikely to occur at runtime. Dynamic analysis, in contrast, does not identify all data dependences that can occur in a program. To address this inaccuracy, we present a new static analysis that predicts the likelihood of occurrence of data dependences to help engineers prioritize their inspection of those dependences. Our preliminary results indicate that our analysis, while having room for improvement, has a promising predictive power.. Introduction Program slicing [] [2] [3] is a well-known technique for software-engineering tasks such as program comprehension and debugging. To obtain a program slice and to perform other software-engineering tasks, data dependences among program statements [4] [5] must be computed. However, identifying all data dependences in a program accurately can be a daunting task because of the complexity of determining the feasibility of program paths (i.e., whether inputs exist that execute those paths) and the imprecision of alias (points-to) analyses [6] [7]. On one hand, static (source-code) analyses [] [2] play safe by identifying all candidate data dependences that may occur at runtime for some execution, but many candidates cannot really occur and the results are imprecise [8] [9]. On the other hand, dynamic (execution) analyses [3] [0] identify data dependences that do occur at runtime for a set of executions but do not reveal which other dependences occur in other. Statement a is data dependent on statement b if a writes to a variable v and b can read v before any other statement rewrites v. executions. To increase precision and reduce the size of slices, efforts have been made to combine static and dynamic aspects of slices [] [2] and to prune slices to focus the attention of developers [3] [4]. However, these approaches do not exploit the fact that some dependences are more likely to occur than others. To address this problem, we present a new model and static analysis that predicts the execution likelihood of data dependences to help developers prioritize their inspection. Our motivation and insight is that not all data dependences are equally likely to occur, so developers should prioritize their inspection efforts typically, on likely dependences over less-likely ones. The model uses structural factors and incorporates points-to analysis information. The analysis is purely static because developers need to know what notyet-observed dependences can really occur. 2 Another advantage of using static analysis is that no test cases or executions are needed to make predictions. We also present a study of the predictive power of our technique. For two subjects, we computed two rankings of data dependences, one ordered by our technique s predictions and the other randomly ordered (to represent current practice 3 ). We compared these rankings with the actual frequencies of occurrence of data dependences for a large number of executions. Our technique predicted relative data-dependence frequencies with an error that is a fraction of the error of the random approach. Despite some simplifying assumptions in our model and not relying on dynamic analysis, these results are very encouraging and promising for tasks that rely on data dependences. 2. Model and Technique A data dependence has two components: a definition (write) of a variable and a use (read) of that variable. 2. Dynamic analysis can still be a useful complement in the future. 3. To the best of our knowledge, no technique distinguishes data dependences by occurrence probability for slicing and other tasks.

2 A data dependence occurs (i.e., is covered) at runtime if the definition is reached and a definition-clear path (i.e., a path without a re-definition of the variable) to its use is then executed. If the variable is accessed via a pointer or reference, however, the dependence occurs only if the memory location where the variable resides is the same at the definition and the use and this location is not overwritten in between. Formally, our model defines the coverage probability of a data dependence (d, u), where d is the definition and u is the use, as P (d,u) = P d P du () where P d is the probability of reaching d from the entry of the program and P du is the probability of reaching u from d through some path in which the variable defined at d is the same one read at u and is not re-defined in between. The latter probability is P du = P p paths(d,u) covered(p) alias(d, u) s: s p s / {d,u} alias( def(s), d) (2) where paths(d,u) is the set of all paths between d and u, covered(p) states that path p is covered, alias(a,b) tells whether the memory location accessed defined or used at a and b is the same, s p states that statement s is in path p, and def(s) is the definition (if any) occurring at s. 4 The last three terms for s in the equation establish that the path p is definition-clear. Equations and 2 represent all necessary conditions for a data dependence to be covered. However, a direct implementation is impractical because of the large or even infinite number of paths in paths(d,u). For that reason, we use the following equation instead: ( ) succeeds(s, d) P du = P s P (alias(d,u)) reaches(s, u) succ(d) (3) where succ(d) is the set of all possible successor statements of definition statement d, succeeds(s, d) states that s is, of all successors, the successor of d that executes right after d, reaches(s, u) states that u is reached along some definition-clear path from s, and alias(d,u) is the event that the variable defined at d is the same one used at u. Equation 3 reduces the problem of computing P du to finding the probability of reaching u through some successor s of the definition and to finding separately the probability that the defined and used variables are aliased (i.e., are the same). 4. Without loss of generality, we assume that each statement in a program writes to at most one variable. The events in the disjunction in Equation 3 are exclusive: exactly one statement succeeds another in an execution and the reaches(s, u) events are independent from each other. Therefore, we can compute the probability P n u of reaching u from d or any statement n other than u via a non-empty definition-clear path as P n u = P = where ( succ(n) s succ(n) i = s i succ(n) succeeds(s, n) reaches(s, u) ) i ( P (succeeds(s j,n)) j= P (succeeds(s i,n)) P (reaches(s i,u)) P (succeeds(m, n)) = succ(n) (4) (5) Equation 5 reflects that, in its current form, our model makes the simplifying assumption that all successors of a statement n (e.g., both branches for an if statement) are equally likely to succeed n. Because, more generally, statement n can be the same as use u, the probability P (reaches(n,u)), also called P n,u for short, is if n = u; P (reaches(n,u))=p n,u = 0 if u / ru(n) (6) P n u if u ru(n) where ru(s) is the set of reachable uses [4] from n. The other component of P du in Equation 3 is the probability of aliasing. Our technique models that probability by using the points-to sets (found by a flowinsensitive points-to analysis [6]) of the pointers at the definition and the use and computing the probability that an element from one set is in both sets: P (alias(a,b)) = P 2Set(a) P 2Set(b) P 2Set(a) P 2Set(b) (7) where a and b are pointers and P2Set(r) is the pointsto set of pointer r. The alias(d,u) event in Equation 3 translates directly into alias(a,b) if a and b are the pointers used at d and u, respectively. Finally, in Equation, the probability P d of reaching the definition from the entry of the program is computed identically to P du by replacing d with the program entry and u with d. There are, however, two exceptions: aliasing is ignored (P (alias(d,u) is ) and, for P n,d in Equation 6 (d replaces u), d ru(s) is always true. Thus, value 0 is not an option for P n,d. This system of equations forms a data-flow problem [4] in which P n,d and P n,u are initialized, for 2

3 : main(int a,int b) { 2: int *p; 3: if (...) 4: p = &a; 5: else p = &b; 6: if (...) 7: swap (p, &a); else 8: if (...) 9: a = b; 0: else swap (&b, &a); : print (a,b); } 2: swap (int* p, int* p2) { 3: int temp = *p2; 4: *p2 = *p; 5: *p = temp; } Figure. Example program to illustrate technique all data dependences (d,u) and all statements n, to if n is d or u, respectively, or 0 otherwise. The technique solves this system by traversing the controlflow graph of the entire program [4] iteratively in post-order. Because the data-flow facts are continuous values (probabilities) the number of iterations needed to converge can be too large. Hence, our technique uses a parameter I (default 4) for the maximum number of times each back-edge [4] is used. When a back-edge e reaches its limit, the target statement of e is removed from the successor set of the source statement of e. 3. Example Figure presents an example we use to briefly illustrate our technique. The program takes a and b as inputs, manipulates the values of these variables based on unspecified conditions (denoted by... and irrelevant for our discussion) and prints the final values of a and b. The helper function swap is also listed. The program uses C-style pointers p, p, and p2. A data dependence in this program is (,4) for variable a, defined at line (the entry) and used at line 4 if the condition at line 3 is true. The probability P d of reaching line from the entry is trivially.0, and the probability P du of reaching the use from the definition is 0.5 because only one of the two successors of line 3 leads to the use (Equations 4, 5, and 6) and the aliasing probability is trivially.0 (Equations 3 and 7). Therefore, the predicted probability for data dependence (,4) for a is 0.5 (Equation ). Consider now dependences (,3) for a and (,4) for b. For both, the reaching probability P n,u (Equation 6) is 0.67 because 4 out of 6 paths call swap. However, the points-to set for p2 at line 3 is {a} and for p at 4 is {a, b}, so the alias probabilities are.0 and 0.5, respectively (Equation 7). Thus, the respective total probabilities are 0.67 ad Table. Subjects, data dependences, and tests subject description LOC data dep. tests Schedule task scheduler NanoXML XML parser The results suggest that (,3) for a is more likely to occur than (,3) for a, which is more likely than (,4) for b. To assess the accuracy of this prediction, suppose that each of the six paths in the program occurs with the same frequency. If so, (,3) for a has frequency 0.66 because it occurs in 4 out of 6 paths, (,3) for a has frequency 0.5 because it occurs in 3 out of 6 paths, and (,4) for b also has frequency 0.5 because it occurs in 3 out of 6 paths. Thus, the prediction is correct for (,3) for a and partly correct for the other two (,3) for a is in second place, although it shares that position with (,4) for b which, nevertheless, is in the last position as predicted (albeit shared). 4. Evaluation The goal of our evaluation was to assess the ability of our technique to predict the occurrence of data dependences. To achieve this goal, we formulated the following research questions: RQ: How accurate is the predicted ranking of data dependences with respect to runtime observations? RQ2: How accurate are those parts of the predicted ranking most likely to be examined first by developers? 4.. Experimental Setup We implemented the equations and technique of Section 2, which we call PrioDUA, as an extension of DUA-FORENSICS [5], our dependence analysis and monitoring toolset which uses an Andersen-style points-to analysis [6]. PrioDUA takes as input a Java program and outputs the data dependences ranked by decreasing probability of occurrence. Table describes our subjects, including the size in lines of code (LOC), the number of data dependences found statically by PrioDUA, and the number of test cases available. Schedule is the Java version of a subject from the Siemens suite and NanoXML is an XML parser. 5 We regard the test cases for these subjects as good representatives of their runtime behavior Methodology To assess the accuracy of PrioDUA for each subject, we measured how closely the ranking computed by PrioDUA, sorted by decreasing probability, predicts 5. Subjects available at the SIR repository: 3

4 average error average error 50% 45% 40% 35% 30% 25% 20% 5% 0% 5% 0% PrioDUA Random 50% 45% 40% 35% 30% 25% 20% 5% 0% 5% 0% PrioDUA Random fraction of ranking fraction of ranking Figure 2. Ranking errors for Schedule the runtime ranking of data dependences, sorted by decreasing frequency. The rank of a dependence is its position in the ranking, from (the most likely or frequent) to D, the number of data dependences in the program. For tied dependences, their rank is the average of the positions of the tied dependences. To obtain the runtime frequencies, we instrumented the subjects using DUA-FORENSICS to collect datadependence coverage, we ran the test suites, and we computed, for each dependence, the percentage of executions in which it occurred. We call dynamic ranking the ranking of dependences by runtime frequency. The accuracy of the PrioDUA ranking is inversely proportional to the error of the ranking. The error for each dependence in the PrioDUA ranking is in [0,): the distance between its position i in that ranking and its position j in the dynamic ranking (i.e., i j ), divided by D. The error for the PrioDUA ranking is the average of the errors of all dependences in it. PrioDUA is useful only if the error of its ranking is less than the error of randomly picking the dependences the Random method. We obtained the expected error of Random analytically as the average expected error of its dependences i, for all i in [,D]. For each dependence i, there are three cases. If dependence i has a dynamic rank less than i, its expected error is the middle point (i )/2 of range [,i), divided by D. If the dynamic rank is i, the error is 0. If the dynamic rank is greater than i, the error is (D i)/2 (the middle of range (i,d]) divided by D. Thus, the expected error for dependence i is the result of multiplying each of these errors by the probability of the corresponding case ((i )/D, /D, and (D i)/d, respectively) and adding these values Results and Analysis Figures 2 and 3 present, for the two subjects, the errors of PrioDUA and Random as percentages (vertical axes) for each fraction of the respective ranking from the top (horizontal axis). Consider Schedule, Figure 3. Ranking errors for NanoXML for example. For the top 5% of the PrioDUA ranking (fraction 0.05) the average error is 4%, for the top half (fraction 0.5) it is 9%, and for the entire ranking (fraction.0) the error is 2% RQ: Accuracy of the PrioDUA ranking. The graphs show that the average error of the entire PrioDUA ranking (at fraction.0) for Schedule is 20.9% and for NanoXML is 5.9%. Both errors are lower than the expected Random errors, which are 33.3%. Thus, for these subjects and test cases, and especially for NanoXML, PrioDUA provides a useful, if not good, static prediction of the relative frequencies of data dependences at runtime RQ2: Accuracy per fraction of the ranking. For Schedule, the average error for the top 5% of the PrioDUA ranking the dependences that developers would inspect first as the most likely ones to occur is the lowest at 4.4%. At the same point, the expected error for Random is 47.5%. For NanoXML, the errors for the top 5% of the rankings are similar. Thus, PrioDUA can be especially beneficial for predicting dependences that occur most frequently in reality. As the fraction of the ranking increases, the average error of PrioDUA tends to grow in Schedule and reaches 20.7% at the end. At the same time, the average error of Random decreases until the fraction is 75% because the Random error is less for dependences near the middle of that ranking, where the expected distance to the dynamic rank decreases. After 75%, that error starts to grow again as dependences tend to be, on average, farther from their dynamic position. For NanoXML, the PrioDUA error also grows initially, but, unlike for Schedule, the error falls dramatically after 5%. The reason is that PrioDUA predicts non-zero probabilities for only,742 data dependences (5.75% of the total), while only,480 data dependences occur at runtime most of them having a non-zero PrioDUA probability. 6 The proximity of 6. For Schedule, almost all data dependences occur at runtime. 4

5 these two numbers means that the PrioDUA rank and the dynamic rank for non-occurring dependences (the majority) are very close, so their errors are small. Thus, as the fraction in the graph of Figure 3 increases, the average error decreases more and more. In all, the results suggest that PrioDUA is not only better than randomly prioritizing data dependences, but also that PrioDUA is particularly strong at predicting dependences located near the top of the ranking. 5. Related Work Static analysis identifies all possible data dependences in a program [4] [5] but, often, many of those dependences are infeasible. Static slicing [] [2], in particular, finds all possible affecting or affected statements but, partly because of data-dependence infeasibility, it leads to large slices [8] [9]. Dynamic analysis, in contrast, finds data dependences that do occur at runtime [3] [0] but normally misses many other data dependences. To increase the precision of data-dependence analysis for slicing, many efforts have been made. Researchers have tried combining static and dynamic aspects of slices [] [2] and pruning slices to focus the attention of developers [3] [4]. These approaches, however, can still miss data dependences and do not consider the differences in likelihood or importance among data dependences. Such differences can lead to a more efficient use of data dependences. Researchers have also sought to address the imprecision of statically-computed data dependences caused by aliasing [6]. Path-sensitive approaches to points-to (alias) analysis can improve the precision of data dependences [5], whereas context- and object-sensitive points-to analysis [7] can improve that precision too, but with a focus on a specialized form of data dependence. None of these approaches, again, and unlike our work in this paper, distinguish data dependences by their likelihood, which would benefit developers. 6. Conclusion and Future Work We presented a new technique for predicting which data dependences are most likely to occur at runtime. The technique helps developers prioritize their inspection of data dependences in a slice and other applications. The model is a system of equations that, while having room for improvement, can prioritize data dependences effectively, as our results suggest. Interestingly, the predictions are especially good at the top of the ranking, where developers would look first. This work can improve not only program comprehension and debugging, but also impact analysis, testing, speculative parallelization, and other tasks. These predictions can be used effectively to prioritize slices. For example, we are currently exploring how to estimate the strength of statements in slices [6]. In the future, we plan to optimize our implementation and improve the precision of the model. For instance, we expect to predict more accurately the successor statements (Equation 5) and experiment with dynamic analysis to improve our predictions without bias. Using an improved model, we will extend our studies to more subjects for greater representativity and to evaluate performance. We also intend to study developers using these predictions for concrete tasks. References [] M. Weiser, Program slicing, IEEE Trans. on Softw. Eng., 0(4): , Jul [2] S. Horwitz, T. Reps, and D. Binkley, Interprocedural slicing using dependence graphs, ACM Trans. on Prog. Lang. and Systems, 2():26-60, Jan [3] B. Korel and J. Laski, Dynamic program slicing, Inf. Process. Lett., vol. 29, no. 3, pp , 988. [4] A. V. Aho, R. Sethi, and J. D. Ullman, Compilers: Principles, Techniques and Tools. A.-W., 986. [5] R. Santelices and M. J. Harrold, Efficiently monitoring data-flow test coverage, in Proc. of Int l Conf. on Automated Softw. Eng., Nov. 2007, pp [6] L. O. Andersen, Program analysis and specialization for the C programming language, Ph.D. Thesis, DIKU, U. of Copenhagen, May 994. [7] A. Milanova, A. Rountev, and B. G. Ryder, Parameterized object sensitivity for points-to analysis for java, ACM TOSEM, vol. 4, no., pp. 4, [8] C. Chambers, M. Mock, D. C. Atkinson, and S. J. Eggers, Program slicing with dynamic points-to sets, IEEE TSE, vol. 3, no. 8, pp , [9] D. Binkley, N. Gold, and M. Harman, An empirical study of static program slice size, ACM TOSEM, vol. 6, no. 2, [0] D. Binkley, S. Danicic, T. Gyimóthy, M. Harman, A. Kiss, and B. Korel, Theoretical foundations of dynamic program slicing, Theoretical Computer Science, vol. 360, no. 3, pp. 23 4, [] G. Canfora, A. Cimitile, and A. D. Lucia, Conditioned program slicing, Information and Software Technology, vol. 40, no. -2, pp , Nov [2] J. Krinke, Effects of context on program slicing, J. Syst. Softw., vol. 79, no. 9, pp , [3] X. Zhang, N. Gupta, and R. Gupta, Pruning dynamic slices with confidence, in PLDI, 2006, pp [4] M. Sridharan, S. J. Fink, and R. Bodik, Thin slicing, in Proc. of PLDI, Jun. 2007, pp [5] H. Pande, W. Landi, and B. Ryder, Interprocedural def-use associations for C systems with single level pointers, IEEE TSE, vol. 20, no. 5, pp , 994. [6] R. Santelices and M. J. Harrold, Probabilistic slicing for predictive impact analysis, Tech. Rep. GIT-CERCS- 0-0, Georgia Inst. of Tech., pp. 0, Nov