[Javapathfinder-svn] SF.net SVN: javapathfinder:[1902] branches/mango/Mango

[<fra...@us...>]

Revision: 1902
          http://javapathfinder.svn.sourceforge.net/javapathfinder/?rev=1902&view=rev
Author:   frankrimlinger
Date:     2009-09-10 21:22:13 +0000 (Thu, 10 Sep 2009)

Log Message:
-----------
It turns out there was a EZ bug in MangoInvokeInstruction.getResolvedMethod().  But the TABLESWITCH formal peer was OK.  Mango was a little worried about whether or not a single instruction could generate multiple branch conditions for the same destination.  This is in fact exactly what TABLESWITCH does in certain cases. So problem was "fixed" by deleting the warning.

However, the LoopGraph (not well named because actually acyclic) generated from a blow up may contain innermost loops, and the problem is that these loops for some reason are not appearing in the loop hierarchy.

OK, what happens here is a little complex.  During phase2, the innermost loops are collapsed, then each remaining non-trivial cluster is blown up.  Then the flow from each alpha to omega is excised, and the process repeats on each excision.  Needless, to say, a fair amount of graph cloning takes place, and the trouble is that the cloned vertices were not inheriting the innermost loop dependency vectors set up by the initial innermost loop collapse.

Fixing this problem is complicated by the fact that the graph cloner uses reflection to create the new vertices, which are not required to be of the same class as those of the input graph.  To safely pass the dependency vector when it is appropriate to do so, chose to put a little hack in the bottleneck routine Graph.associatedOutputVertex().  TRICKY: some loops now appear more than once in the dependency graph structure, for example in loopTests.fibonocci.  Rather than fight city hall, just be sure to eliminate duplicates from the final dependency vector.

Incidentally, fibonocci is a fine example of mutual co-recursion, so keep testing it as automation proceeds.

YIKES.  Inspection of A!_B!_A!_Component_loopTests.nested_blowup.main(I)V reveals that the acyclic graph of a blowup need not be connected. This means in some cases you do cross over connectors when seeking omega.  But its ok, because you only cross over to connector entrypoints that are entrypoints of the SAME graph, and this is easily checked.  


CORRECTION: the branching logic in 1899 for blowups should read

Do not go down any edge which only leads to a component sink other than omega, unless you are going to connect to an entrypoint of the same component.  (All such entrypoints will ultimately lead to omega).

NEXT:  Clean up the dependency tree of all entrypoints, starting at the root "Java Code Entrypoints" in order to develop the dependency tree of modules required for target selection.

Modified Paths:
--------------
    branches/mango/Mango/Mango/src/mango/graph/msg/Graph2DViewCreateRequestMsg.java
    branches/mango/Mango/Mango/src/mango/worker/mangoModel/BackupAlg.java
    branches/mango/Mango/Mango/src/mango/worker/mangoModel/edge/SimpleLoopPath.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/vertex/LoopVertex.java
    branches/mango/Mango/javapathfinder-mango-bridge/mango/scanner/MangoInstruction.java
    branches/mango/Mango/javapathfinder-mango-bridge/mango/scanner/MangoInvokeInstruction.java


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.