Method call graph
If the program being passed through Wasp is large or complicated, data flow analysis may slow down drastically at some stage. The method call graph may help you to understand which methods cause the difficulties.
There are two sections in a method call graph file. The first part shows, for each method, which methods are called in its body. The second part shows, for each method, from what methods it may be called.
Each method belongs to a certain layer. Methods in the layer 0 call no other methods. A method P that belong to the layer N, may call a method belonging to a layer whose number is less than N (or is equal to N if the method P is recursive).
A method layer in the first section of a method call graph has the following structure:
----------------------- LAYER N ----------------------
# <calls in the body of the first method>
............................................ and so on
# <calls in the body of the last method>
If the method from the layer N was processed by Wasp, information for it has the following structure:
# <method name>(<number of contexts>, <def number>)-->
<list of called methods>
The amount of memory and time required for analysis of the method correlates with the value:
ln(<number of contexts>) * <def number>.
If the number of contexts is greater than 200 (this may happen for a recursive method) then the analysis of such method is slow.
In the beginning of the first section, the external methods (see Analysed configuration) are showed. The Wasp analysis will be very slow and imprecise if <def number> is high for some external method.
A fragment of the first section of a method call graph is shown below.
----------------------- LAYER 23 ----------------------
# jess.JessTokenStream.nextToken(28,715)!-->
JessTokenStream.prepareSexp!, JessToken.toString,
java.lang.StringBuffer.append,
util.Stack.empty, Stack.pop;
# jess.JessTokenStream.head(1,565)-->
JessTokenStream.prepareSexp, JessToken.toString
java.util.Stack.empty, Stack.pop, Stack.peek, Stack.push;
For each method (the nextToken and head), called methods in its body are sorted with respect to packages. The token "!" indicates methods whose analysis has not been finished yet. In the above fragment, method prepareSexp and, as a result, nextToken were still processed by data flow analysis when the method call graph has been printed. This may give you some idea on the progress of Wasp analysis.
In the second section of a method call graph, each line has the following structure:
<method name><--<list of calling methods>
Each call in the <list of calling methods> is
<method name>(<line number>, <column number>)
In the second part of a method call graph file, calls to each method are shown. For instance, if you want to find out from what place the constructor Fact is called, search for the string "Fact.Fact<" in the call graph file. You might find a fragment like:
# jess.Fact.Fact<--
Rete.initTransientMembers(486,32 487,30), Rete.clear();
Jesp.parseFact(568,16)
which shows that methods initTransientMembers, clear, and parseFact have calls of Fact in their bodies, but only methods initTransientMembers and parseFact were processed by data flow analysis, because coordinates of calls are shown in brackets only for these two methods. The method slH.clear did not undergo data flow analysis yet.
|
