SableWiki - Diff: ClassResolver

Differences between current version and predecessor to the previous major change of ClassResolver.

Other diffs: Previous Revision, Previous Author

Newer page: version 15 Last edited on March 8, 2005 4:26 pm. by cpicke
Older page: version 14 Last edited on February 25, 2005 11:56 pm. by cpicke
@@ -1,75 +1,5 @@
-When Soot begins executing, it "resolves" all classes that it may need information about (for example, so that it has enough of the type hierarchy to perform the Jimple typing algorithm). This procedure consists of loading the classes and following references to other classes according to the procedure described on this page. It is important that all classes that will be needed are loaded at the start, because many of the algorithms and structures within Soot are not designed to cope with an expansion in the set of known classes.  
-  
-Earlier versions of Soot used a simple algorithm which resolved all classes to be processed, and the transitive closure of any classes referenced from any classes already resolved. As of version 2.2., Soot uses a more complicated algorithm to avoid resolving as many classes. The algorithm is based on "resolving levels". Each level specifies which operations are supported on a class resolved at that level, and which referenced classes must be resolved at which level to support those operations. The -full-resolver switch causes Soot to use the old, simple algorithm.  
-  
-!Levels of resolving  
-  
- * Dangling - mimics current Phantom behaviour  
- * Hierarchy - we know the hierarchy of the class and that's it  
- * requires at least Hierarchy for all supertypes and enclosing types  
- * OK to declare things to be this type  
- * Signatures - we know the signatures of all methods and fields  
- * requires at least Hierarchy for all referred to types in these signatures  
- * requires Signatures of superclass and superinterfaces  
- * OK to call methods on this type (or its supertypes)  
- * Bodies - we can now start loading the bodies of methods  
- * for all referred to methods and fields in the bodies, requires signatures for the method receiver and field container, and hierarchy for all other classes referenced in method references  
- * Current implementation does not distinguish between the receiver and other references. Therefore, it is conservative and brings all of them to signatures. But this could/should be improved.  
- * All operations become possible  
-  
-!Kinds of classes  
-  
- * Phantom - we don't have an input file for the class, so we make it up as we go along:  
- * extends java.lang.Object, implements nothing, has all methods that we see references to  
- * can never get to Bodies, but can get to Signatures  
- * Library - is referred to by the classes being processed, but is never written out  
- * in single-file mode, is never jimplified  
- * in whole-program mode, is jimplified but never written out  
- * in single-file mode, must be at least Hierarchy; if an application class has a field/method ref to it, must be at least Signatures  
- * in whole-program mode, must be at least Bodies  
- * Application - is jimplified and written out  
- * must be at least Bodies  
-  
- * -full-resolver causes all classes to be resolved at Bodies, recursively following all references. Phantom classes are only resolved at Signatures. This behaviour is also triggered by -ws (whole shimple), selecting dava output format, and by -w (whole program). Note that -w is implied by various other options, so there are a number of possible triggers for full resolving mode.  
- * -app causes all classes referred to by Application classes to recursively become Application classes, unless they are in one of the packages specified by -i/-x  
-  
-Note that -app and -full-resolver are orthogonal. -full-resolver affects the level at which classes are resolved and whether they are resolved at all, and -app affects whether classes are treated as application classes or not.  
-  
-When -full-resolver mode is not on, a root set of classes is resolved at some specified level, and the rules given above for each level are used to recursively resolve classes. The root set of classes and the associated level is determined as follows:  
-  
- * All classes specified on the command-line are resolved at Bodies  
- * A certain set of "basic" classes is resolved. This set includes various of the core java.lang classes (and java.io.Serializable), at either Signatures or Hierarchy  
- * Clients can add to the set of basic classes by calling Scene.v().addBasicClass themselves before invoking soot via soot.Main  
- * Clients that don't use soot.Main should call either Scene.v().loadBasicClasses() or Scene.v().loadNecessaryClasses() after setting up command-line options if appropriate and adding basic classes but before doing anything else. loadBasicClasses will resolve just the basic classes, and loadNecessaryClasses will resolve the basic classes and those specified via command-line options.  
-  
-A good rule of thumb is that you will need full resolver mode when doing interprocedural analysis, but won't if just doing intraprocedural analysis. More precisely, without full resolver mode on it is safe to analyse or transform the bodies of classes that were specified on the command-line, but it is not safe to follow references to other classes and analyse those.  
-  
-!What various methods do  
- * addBasicClass puts the class supplied in a list for later processing by loadBasicClasses  
- * loadBasicClasses tries to load all the classes in the basic classes list  
- * loadNecessaryClasses calls loadBasicClasses, and then loads classes that were specified on the command-line  
- * loadClassAndSupport loads a class at level Bodies, unless it is Phantom in which case it is loaded at Signatures  
- * loadClass loads a class at the given level  
- * loadClass and loadClassAndSupport should probably be deprecated. In particular it is very likely that calling them will cause an exception if you do so after the initial resolving process is done, unless the class specified has already been loaded at the appropriate level by one of the mechanisms specified above  
-  
-!Transitions between levels  
-  
- * Dangling -> Hierarchy  
- * Determine superclass, interfaces implemented, and outer class, and bring them all to at least Hierarchy.  
- * Hierarchy -> Signatures  
- * Determine the set of methods and fields. For each class referenced in method/field signatures, bring it to at least Hierarchy.  
- * Determine superclass and interfaces implemented, and bring them all to at least Signatures.  
- * Signatures -> Bodies  
- * For every reference to a class, bring the class to at least Signatures.  
-  
-=========================  
-NEW REVISED VERSION BELOW  
-=========================  
-  
-The following is a rewritten version of the above. It is still a draft and in particular relies on some changes to Soot that have not yet been checked in.  
-  
- Soot is designed in such a way that all the classes it is going to load should be loaded in an initial phase, known as "resolving". A number of parts of Soot are not designed to work well with new classes being loaded after they have built their data structures. 
+Soot is designed in such a way that all the classes it is going to load should be loaded in an initial phase, known as "resolving". A number of parts of Soot are not designed to work well with new classes being loaded after they have built their data structures. For example, Soot needs a certain amount of the type hierarchy loaded before it tries to perform the Jimple typing algorithm
  
 As a result, it is not advisable to load classes at arbitrary times during the execution of Soot or a tool built on top of it. The purpose of this document is to explain how Soot decides which classes to load and how users and extenders of Soot can influence this process. 
  
 The first key point is that class loading is not just a binary switch where a given class must be either loaded or not loaded. The status of a class within Soot is measured along two axes. Firstly, a class can be loaded at multiple "levels", which controls how much of the structure and contents of a class has been processed by Soot. Secondly, there are multiple "kinds" of classes, depending on how Soot loaded them and what it intends to do with them. The concepts are mostly orthogonal, although some combinations of kind and level are invalid. 
@@ -108,9 +38,9 @@
 Soot has two different modes of resolving, normal and full. Which mode it is in affects how many classes are resolved and at what level this is done. 
  
 In normal mode, Soot starts from a certain root set of classes (the "application" and the "basic" classes, described below), and does the minimum to resolve them according to the constraints above. This mode is suitable for carrying out intraprocedural analysis only, but Soot startup is relatively fast. 
  
-In full mode, Soot starts from this same root set of classes, but they are all resolved at Bodies, and all classes referred to by them are resolved at Bodies, and so on. This mode is suitable for carrying out interprocedural analysis; because Soot has to do much more work it takes significantly longer (a few seconds, normally) to startup in this mode. 
+In full mode, Soot starts from this same root set of classes, but they are all resolved at Bodies, and all classes referred to by them are resolved at Bodies, and so on, resolving everything in the transitive closure of referenced classes . This mode is suitable for carrying out interprocedural analysis; because Soot has to do much more work it takes significantly longer (a few seconds, normally) to startup in this mode. This is the old and simple algorithm used by Soot prior to version 2.2.
  
 Full resolving mode can be turned on explicitly by the -full-resolver command-line option. It is also triggered by -ws (whole shimple), selecting the dava output format, and by -w (whole program). Note that -w itself is implied by various options, so there are a number of possible triggers for full resolving mode. 
  
 !Kinds of classes