Vijay Krishna's Notes http://vijaykrishna.posterous.com Most of my notes as a student of computer software and everything around it. posterous.com Wed, 08 Feb 2012 17:44:00 -0800 Review on Pruning Dynamic Slices with Confidence http://vijaykrishna.posterous.com/review-on-pruning-dynamic-slices-with-confide http://vijaykrishna.posterous.com/review-on-pruning-dynamic-slices-with-confide

Original Paper at http://dl.acm.org/citation.cfm?id=1134002

This paper presents a technique to reduce a dynamic slice derived out of a dynamic dependence graph of a program, with the goal of reducing the search space (the statements in the slice which need to be inspected) for finding the fault. The assumption the paper makes is that the faulty statement will be contained in the slice. However, later in the evaluations of the technique it does report of situations where that is not the case, making it one of the limitations of the technique proposed. A work around with relevant slicing is however proposed. The reason why this is a limitation is because the pruning is done with the motivation of locating faults, and if the fault itself is missing in the slice, it is not helpful. Nonetheless, it is to be noted that the basic idea of tagging each statement with a confidence value depending on a property such as relation with an incorrect output, or a possible security problem with in the code is still valuable, especially if the idea is to be applied to reduce the search/inspection space for the user. Thus, the primary contribution of the paper is the method of pruning based on a very specific property of the program like a faulty/incorrect output. The fact that this can be used for fault localization, in my opinion is the secondary contribution.

Assuming that the fault exists in the slice, the approach that the paper takes in pruning the statements is by assigning each statement in the slice with a confidence value between 0 and 1, with 1 being highly confident. High confidence indicates the statement is not responsible for the incorrect output and thus can be removed or 'pruned' from the dynamic slice with 'confidence'. The paper shows that removing just statements with a confidence value of 1, results in a reduction which ranges from 1.79 to 190.57 times of the number of distinct statements in the regular slice. The paper also reports the effects of having a threshold on the confidence values for inclusion in the pruned dynamic slice (PDS). With decreasing the threshold value the size of the slice decreases, but so does the effectiveness of localizing faults with that slice.

The confidence values are evaluated in the following manner. Each statement is assigned a confidence of 1 if it is involved in computing at least one of the correct output values, but is not involved in calculating any of the incorrect values. A statement is assigned 0, if it is involved in the computation of only incorrect values and none of the positive values. The ambiguity comes in the case of statements which are responsible for the computation of both correct and incorrect outputs. For these statements the following intuition is applied. If a given statement computes any value, which when changed in any manner results in changing the final output from correct to incorrect, then we know that the original value that was produced at that statement was correct. This shows that there is a direct correlation between the output and values produced by that statement. Had the output remained correct , i.e. unaffected despite changing the values produced at a statement, then it is reasonable to say that the there is no or little correlation between the values produced at that statement and final set of correct outputs. Thus, not allowing us to say with confidence that the values being produced at that statement are indeed correct. This idea is used to compute those possible number of values produced at a given statement which when changed do not effect the final correct outputs being produced, making them incorrect. In the case of a high confidence statement (confidence value = 1) such values do not exist. In the case zero confidence statements, all the values produced at that statement have no impact on the final correct outputs being produced. The mathematical relation in the paper depends on such intuition. It is important to note here that the confidence value indicates the confidence we have in the fact that a value produced at a statement is correct not if that value is incorrect. It is not apparent if low confidence indicates that incorrect values are being produced at a statement.

This intuition draws my attention to the fact that the technique requires the program to produce an output. This I feel is a major limitation on the part of the process of pruning itself. The way the technique is described, if the output is not produced, the concept of a correct/incorrect output is non-existent and one cannot assign confidence values to the statements. The other big problem with this kind of reasoning is that if the very first output produced is incorrect then the approach is inapplicable, and the paper notes this in its experimental section. On a different note, the paper states that this technique is limited to only one error. However, I am not quite certain if this is a limitation. Digiuseppe and Jones1 show in their study of fault interactions, how a single fault tends to obfuscate other faults. So even if there are multiple faults, chances are that this or any technique for fault localization will end up detecting only one fault at a time.

The paper also talks about using the confidence values to rank statements in a dynamic slice and presenting it for user inspection. The only problem with providing users with a such a ranked list of source code statements is that users will be looking at those lines without any context, because these lines are probably not directly related with each other especially in the ranked order. Without looking into the source code, they will have no way of knowing if one of the lines in that list is the fault or not. And this problem will only compound if the user has little or no idea about the source code.

Overall, I found this technique to be sound in its basis for reducing a search space in general, but limited when it comes to applying it for locating faults.

1 N. Digiuseppe and J. A. Jones Fault Interaction and its Repercussions, Proceedings of the 27th IEEE International Conference on Software Maintenance (ICSM). http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6080767&tag=1

Permalink | Leave a comment  »

]]>
http://files.posterous.com/user_profile_pics/1369599/pic.jpeg http://posterous.com/users/hcGXxsTkwP6SS Vijay Krishna Palepu vpalepu Vijay Krishna Palepu
Wed, 08 Feb 2012 17:36:00 -0800 Review on Cost Effective Dynamic Program Slicing http://vijaykrishna.posterous.com/review-on-cost-effective-dynamic-program-slic http://vijaykrishna.posterous.com/review-on-cost-effective-dynamic-program-slic

Original paper at http://dl.acm.org/citation.cfm?id=996855

This paper talks about a set of optimizations that can be applied while constructing dynamic dependence graphs for programs, thereby reducing the size and the traversal times of these graphs. Since these aspects of a dynamic dependence graph incur costs on computing slices, reducing them makes the process faster. The paper makes a very basic assumption about the basic blocks of a program and their associated 'time stamps' in the context of computing the complete dynamic dependence graph. The assumption is that each basic block will be given a time stamp which will then be associated to all local dependencies occurring in that block. My first doubt at this stage is on the definition of a basic block: is it a function, the body of a loop or individual bodies of a conditional statement? The paper does not clarify this. Assuming that it is the standard definition1, such a time stamp scheme might not be right in the context of concurrent programs, where variables are shared between basic blocks.

On a different note, the paper notes that simply drawing edges between statements of code is not enough, but accurate information should be shown in the form of labels, about all the execution instances which are associated with that dependence being formed. This will also lead to an understanding of the context of the program run. However, it is noted further that the amounts of such labels for each edge will depend on the extent of the program's execution itself. Thus, long running programs are likely to have high amounts of such labels. The optimizations proposed in this paper look at reducing the needs to capture all those labels, and on particular occasions even reducing the edges themselves. The reduction is achieved by a basic principle of edge sharing. Or in other words, if you have a set of edges/labels which will occur together in all or a given set of execution instances then a common edge or a common edge without labels can be drawn which will represent all of those dependencies or execution instances. Here comes the question of loss of information. It is to be noted here that the information being provided by such optimizations are still accurate, but they are abstracted. Given a situation where you want to tag individual execution instances with specific information such as being associated to pass/fail test runs, then you have lost some information with the kind of abstraction that these optimizations introduce. Of course this is a very specific situation, and the paper I assume is looking at more general situations where dynamic slices are required. It would have been better for the paper had certain concrete examples been provided where such an optimized slice might be useful. However, I do understand that the paper is grounded in theory and perhaps such a discussion is out of scope for the paper.

On the subject of the optimizations themselves, in my opinion they are an efficient use of the statically derived information about the program's statement dependencies. The simplest category of optimizations come from statically inferring dependencies which are definite to occur. Edges between statements and unambiguous and sole definitions or control ancestors are instances of such dependencies. These edges need not store label information. The time stamp information is also a compile time constant for these edges as shown in the paper. The next set of optimizations involve transformations of the nodes themselves. When a node has two distinct definition-parents or control-ancestors, then the node is duplicated to serve each parent or ancestor separately. This allows us to statically infer the edges in these transformed nodes. At times, when two uses or control dependent nodes have the same definition-parent or the control-ancestor, then those two nodes are linked together and the dependence edge is drawn only between one of them to the parent or ancestor, thus reducing the number of edges themselves. Furthermore, such transformations can also depend on the path taken between the statements with dependencies. That is different (specialized) nodes can be created for specific paths based on how the dependencies can be identified along that path. The third and final set of transformations are to reduce redundant edges. This is done by merging common common def-use edges between two different variables/objects or common data and control dependent edges into one. This reduces the redundancy as it eliminated the edges. Again, here, a question of information loss comes up. You cannot now, for instance distinguish between control and data dependencies in certain places. And if a situation arises where such a distinction is necessary, then these optimizations won't be helpful.

The evaluations of the optimizations showed the margin by which they reduced the size of the dependence graph and time taken to compute the slices from such an optimized graphs. Furthermore, it showed how each optimization technique contributed to the size reduction. This I felt was the most insightful. It especially shows that OPT1 (optimization 1) which involved inferring local (to a block), data dependences was the most effective at reducing the sizes of the graphs. This is to me is an important result. OPT1 was the most fail safe optimization of all, in that it rejected labels for those edges which are sure to happen no matter what. The other optimizations while valid only if a set of preconditions were met or certain transformations were applied. Also, OPT1 did not go for blatant abstraction which could result in information loss. On the whole, all the optimizations together reduced the graph size by significant margin. And thus the time taken to calculate the slices was obviously far lesser. We should however question the information presented in these slices and their effectiveness. Also, might it be possible to just apply OPT1 even though it would not achieve complete optimization but reduces the graph enough for a fast computation of the slice? It would have been interesting to note the separate times taken for slice computation for each individual optimization.

1 Frances E. Allen. 1970. Control flow analysis. SIGPLAN Not. 5, 7 (July 1970), 1-19. DOI=10.1145/390013.808479 http://doi.acm.org/10.1145/390013.808479

Permalink | Leave a comment  »

]]>
http://files.posterous.com/user_profile_pics/1369599/pic.jpeg http://posterous.com/users/hcGXxsTkwP6SS Vijay Krishna Palepu vpalepu Vijay Krishna Palepu