Exploiting the empirical characteristics of program dependences for improved forward computation of dynamic slices

Abstract

Forward computing algorithms for dynamic slicing operate in tandem with program execution and generally do not require a previously stored execution trace, which make them suitable for interactive debugging and online analysis of long running programs. Both the time and space requirements of such algorithms are generally high due to the fact that they compute and maintain in memory the dynamic slices associated with all variables defined during execution. In this paper we empirically identify several characteristics of program dependences that we exploit to develop a memoization-based forward computing dynamic slicing algorithm whose runtime cost is better than that of any existing algorithm in its class. We also conduct an empirical comparative study contrasting the performance of our new algorithm to the performance of four other algorithms. One is a well known basic algorithm, and the remaining three, use reduced ordered binary decision diagrams (roBDDs) to maintain dynamic slices. Our results indicate that the new memoization-based algorithm is: (1) considerably more time and space efficient than the basic algorithm and one of the roBDD-based algorithms designed to be suitable for online analysis; and (2) comparable in terms of time efficiency but consistently more space efficient than the remaining two roBDD-based algorithms.

Appendix 1

We now provide a high level walkthrough of our algorithm when applied to a simple snippet of Java code. For simplicity, we use a version of our algorithm that processes pairs of slices only. We also discuss our walkthrough in the context of Java source code as opposed to byte code. Suppose we have the following program:

• (1) int a = 1;

• (2) int b = 2;

• (3) int c = 3;

• (4) int d = 4;

• (5) int i = 0;

• (6) while (i < 1000){

• (7) a = a + b;

• (8) b = b + 1;

• (9) if (b % 2 = = 0) {

• (10) a = a + c;

• (11) }else {

• (12) a = a + d;

• (13) }

• (14) i + + ;

• (15) }

Table 8 yields the state of the slices corresponding to each of the variables, as well as selected modifications to the main data structures during each timeslot. Time T = 0 corresponds to the state before the program begins execution, time T = 1 corresponds to the time just after the first statement (i.e. line 1) has executed, and so on. The main actions taken by our algorithm at each time slot are described below:

• T = 0: No slices get computed and none exist yet.

• T = 1: The variable a is only influenced by statement 1, so its slice is the set {1}. Since {1} is the first slice which comes up in the program, it is assigned uid 1 and its corresponding entry ({1},1) is added to sliceToUid.

• T = 2: The variable b is only influenced by statement 2, so its slice is the set {2}. Slice {2} is assigned uid 2 and its corresponding entry ({2},2) is added to sliceToUid.

• T = 3, 4 and 5: Actions similar to the above are taken when executing statements 3, 4, and 5.

• T = 6: The following is done when the while statement executes for the first time:

  • 1. The only direct influence on statement 6 is statement 5 which was associated with slice ({5}, 5) at T = 5.

  • 2. Since statement 6 must be included in the resulting slice, slice {6} is computed, it is assigned uid 6, and sliceToUid is updated with entry ({6},6).

  • 3. Slice {5, 6} is computed, it is assigned uid 7, and sliceToUid is updated with entry ({5, 6},7).

  • 4. uid2TupleToUid is updated with ((5,6),7) to indicate that the unioning of the two slices identified by uid 5 and uid 6 results in a slice identified by uid 7.

• T = 7: The slice of the variable a defined by statement 7 is computed as follows:

  • 1. The direct influences on statement 7 are found to be statements 1, 2, and 6, which are associated with slices {1}, {2}, and {5, 6}, respectively.

  • 2. Slices {1} and {2} are merged which results in adding entry ({1, 2},8) to sliceToUid and entry ((1,2),8) to uid2TupleToUid.

  • 3. Slices {1, 2} and {5, 6} are merged which results in adding entry ({1, 2, 5, 6},9) to sliceToUid and entry ((7,8),9) to uid2TupleToUid.

  • 4. Since statement 7 defines a, entry ({7},10) is added to sliceToUid.

  • 5. Finally, {7} and {1, 2, 5, 6} are merged which results in adding entry ({1, 2, 5, 6, 7},11) to sliceToUid and entry ((9,10),11) to uid2TupleToUid

• T = 8: Similarly, the slice of the variable b defined by statement 8 is computed as follows:

  • 1. The direct influences on statement 8 are found to be statements 2, and 6, which are associated with slices {2} and {5, 6}, respectively.

  • 2. Slices {2} and {5, 6} are merged which results in adding entry ({2, 5, 6}, 12) to sliceToUid and entry ((2,7),12) to uid2TupleToUid.

  • 3. Since statement 8 defines b, entry ({8}, 13) is added to sliceToUid.

  • 4. Finally, {8} and {2, 5, 6} are merged which results in adding entry ({2, 5, 6, 8},14) to sliceToUid and entry ((12,13),14) to uid2TupleToUid

• T = 9: The slice of the if statement is computed as follows:

  • 1. The direct influences on statement 9 are found to be statements 6 and 8, which are associated with slices ({5, 6},7) and ({2, 5, 6, 8},14), respectively.

  • 2. The entry ({2, 5, 6, 8},14) representing the union of {5, 6} and {2, 5, 6, 8} has already been added to sliceToUid at T = 8, so there is no need to add a corresponding new entry. But entry ((7,14),14) is added to uid2TupleToUid to avoid any future unioning of {5, 6} and {2, 5, 6, 8}.

  • 3. Entry ({9}, 15) is added to sliceToUid since {9} should be part of the slice.

  • 4. Finally, {9} and {2, 5, 6, 8} are merged which results in adding entry ({2, 5, 6, 8, 9},16) to sliceToUid and entry ((14,15),16) to uid2TupleToUid.

• T = 10, 11, 12, 13, and 14: Actions similar to what is described above are taken.

• T = 15: When statement 9 executes for the second time, no new entries are added to sliceToUid or to uid2TupleToUid, and this is why:

  • 1. The direct influences on statement 9 are statements 6 and 8, which are associated with slices ({5, 6}, 7) and ({2, 5, 6, 8}, 14), respectively.

  • 2. uid2TupleToUid already contains entry ((7,14),14), so no unioning of {5, 6} and {2, 5, 6, 8} is needed.

  • 3. sliceToUid already contains entry ({9}, 15), so there is no need to add a corresponding new entry.

  • 4. uid2TupleToUid already contains entry ((14,15),16), so no unioning of {2, 5, 6, 8} and {9} is needed.

  Table 8 Algorithm walkthrough

Similar to the case for T = 15, for T = 17, 19, 21, 23 and higher no new entries are added to sliceToUid or to uid2TupleToUid, that is no slice computation are necessary (only look ups and fetches from uid2TupleToUid are performed). Therefore, in the subsequent 996 iterations of the loop, merging pairs of slices takes constant time on average.