From: <fra...@us...> - 2009-09-14 05:08:09
|
Revision: 1905 http://javapathfinder.svn.sourceforge.net/javapathfinder/?rev=1905&view=rev Author: frankrimlinger Date: 2009-09-14 05:08:00 +0000 (Mon, 14 Sep 2009) Log Message: ----------- A SuperCpnSym represents a Graph whose entrypoints are MethodEntrySym's. Each such MethodEntrySym must, at least for the time being, fire up a DefinitionManager. A MethodEntrySym is a GraphicSym, and so has an outgoingConnections field, which is a set of GraphicConnection's. There are many kinds of GraphicConnection, but the relevant one for walking the forward flow are the superCpnConnection and subCpnConnection >From the point of view of walking forward flow, the only wrinkle introduced by a system with mutual co-recursion is that not all entrypoints of a SuperCpnSym are associated with the same method. In fact, there will be one such entrypoint for each method of the system. This is not a problem because each entrypoint gets its own DefinitionManager anyway. Introduced GraphIterator class, and migrated graph walking functionality so nested walks can take place. This ancient bug is finally put to rest. Compared modelling of "frank" configuration in Mango versus MangoBaseline, precisely 28 seconds in both cases, so that there is zero performance hit using the GraphIterator class. Generated the flat list of terminal SuperCpnSym's. However, what we really want is the corresponding flat list of MethodEntrySym's. Not necessarily one-to-one because of mutual corecursion. Also on the fly create maps MethodInfo--> Vector<Integer> ClassInfo --> Vector<Integer> Which map each associated method and class to the corresponding indices of the flat vector. Now give a target that maps to a MethodInfo or ClassInfo, you can map to an index and hence a MethodEntrySym. But not done yet. We really need to find the least dependent module associated with MethodEntrySym. In order to do this, need to back off to the SuperCpnSym, and flatten its forward flow, picking up all SuperLoopSym's which are destinations of a SuperBlowUpSym's, and all LoopSym's. You don't need to bother with initial SuperLoopSym's as these do not contain an alpha-omega pair. So, to summarize, once you deduce the "closest" MethodEntrySym, you flatten its *relevant* forward flow. This give you the order of component execution for the ComponentChoiceGenerator, modulo duplicate entries. TODO: finish the target selection algorithm by acquiring the nearest MethodEntrySym and preparing the required ordering for the ComponentChoiceGenerator. Modified Paths: -------------- branches/mango/Mango/Mango/src/mango/worker/mangoModel/BackupAlg.java branches/mango/Mango/Mango/src/mango/worker/mangoModel/graph/AcyclicGraph.java branches/mango/Mango/Mango/src/mango/worker/mangoModel/graph/Graph.java branches/mango/Mango/Mango/src/mango/worker/mangoModel/graph/LoopGraph.java branches/mango/Mango/Mango/src/mango/worker/mangoModel/sym/graphic/GraphicSym.java branches/mango/Mango/Mango/src/mango/worker/mangoModel/sym/graphic/SuperVertexClassSym.java branches/mango/Mango/Mango/src/mango/worker/mangoModel/sym/superVertex/SuperBlowUpSym.java branches/mango/Mango/Mango/src/mango/worker/mangoModel/sym/superVertex/SuperEntrySym.java branches/mango/Mango/Mango/src/mango/worker/mangoModel/sym/superVertex/SuperLoopSym.java branches/mango/Mango/Mango/src/mango/worker/mangoModel/sym/superVertex/SuperVertexSym.java branches/mango/Mango/Mango/src/mango/worker/mangoModel/sym/ucon/UconSym.java branches/mango/Mango/Mango/src/mango/worker/mangoModel/vertex/AcyclicVertex.java branches/mango/Mango/Mango/src/mango/worker/mangoModel/vertex/CpnVertex.java branches/mango/Mango/Mango/src/mango/worker/mangoModel/vertex/SuperCpnVertex.java branches/mango/Mango/Mango/src/mango/worker/msg/OpenDefinitionMsg.java branches/mango/Mango/Mango/src/mango/worker/msg/SelectTargetMsg.java branches/mango/Mango/javapathfinder-mango-bridge/mango/rewriter/synthetic/Vertex.java Added Paths: ----------- branches/mango/Mango/Mango/src/mango/worker/mangoModel/graph/GraphIterator.java This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. |