Databases Reference
In-Depth Information
7.5.1.2
Dynamic Setup
Because the incremental cost of checking for additional patterns at runtime
is generally low, when reviewing the patterns in Eclipse for inclusion in our
dynamic experiments, we were fairly liberal in our selection. We would usually
either just look at the method names involved in the pattern or briefly examine
a few usage cases. We believe that this strategy is realistic, as we cannot
expect the user to spend hours poring over the patterns. To obtain dynamic
results, we ran each application for several minutes on a Pentium 4 machine
running Linux, which typically resulted in several thousand dynamic events
being generated.
7.5.2 Discussion of the Results
Overall, 32 out of 56 (or 57%) patterns were hit at runtime. Further-
more, 21 out of 32 (or 66%) of these patterns turned out to be either usage
or error patterns. The fact that two thirds of all dynamically encountered
patterns were likely patterns demonstrates the power of our mining approach.
In this section we discuss the categories of patterns briefly described in
Section 11.2 in more detail.
7.5.2.1
Matching Method Pairs
The simplest and most common kind of a pattern detected with our mining
approach is one where two different methods of the same class are supposed to
match precisely in execution. Many of known error patterns in the literature
such as h fopen , fclose i or h lock , unlock i fall into the category of function
calls that require exact matching: failing to call the second function in the
pair or calling one of the functions twice in a row is an error.
Table 7.5 and 7.6 list matching pairs of methods discovered with our mining
technique for corrective and regular ranking, respectively. The methods of
a pair ha;bi are listed in the order they are supposed to be executed, e.g.,
a should be executed before b. For brevity, we only list the names of the
method; full method names that include package names should be easy to
obtain. A quick glance at the table reveals that many pairs follow a specific
naming strategy such as pre { post , add { remove , begin { end , and enter { exit .
These pairs could have been discovered by simply pattern matching on the
method names. Moreover, looking at method pairs that use the same prefixes
or suxes is an obvious extension of our technique.
However, a significant number of pairs have less than obvious names to
look for, including h HLock , HUnlock i, h progressStart , progressEnd i, and
h blockSignal , unblockSignal i. Finally, some pairs are very dicult to rec-
ognize as matching method pairs and require a detailed study of the API to
conrm, such as h stopMeasuring , commitMeasurements i, h suspend , resume i,
etc.
 
Search WWH ::




Custom Search