soot.jimple.toolkits.pointer.nativemethods.NOTES Maven / Gradle / Ivy

Go to download
Show more of this group Show more artifacts with this name
Show all versions of robovm-soot Show documentation
RoboVM fork of Soot - A Java optimization framework
There is a newer version: 2.5.0-9
NOTES on native methods side-effect simulation:

1. Environment:

   Since JVM allows multi class loaders and dynamic class loading, 
   a static analysis may not be about to figure out exact classes 
   get loaded. This should be rear cases in our analyzed benchmarks.

   Our analysis assumes a closed world environment which means all
   classes will be loaded are presented in our environment when
   being analyzed. 

   We list known environmental constants assumed by native methods.
   This is not a complete list. Each of following classes has one 
   abstract object existing:
   
    java.lang.ClassLoader 	Environment.getClassLoaderObject();
    java.lang.Process		Environment.getProcessObject();
    java.lang.Thread		Environment.getThreadObject();
    java.io.FileSystem		Environment.getFileSystemObject();
    java.lang.Class             Environment.getClassObject();
    java.lang.reflect.Field     Environment.getFieldObject();
    java.lang.reflect.Method    Environment.getMethodObject();
    java.lang.reflect.Constructor
				Environment.getConstructorObject();
    
   Allowing only one abstract object exist means any 'new xxx()' expression
   should return the only object of the class 'xxx'.
        
   The field of above constant object should have one object also. (TODO!)

   There are some other constants need to be considered separately.

2. Strings:

   Many native methods return strings. Since java.lang.String is final,
   we can use a single 'String' object for any string from unknown sources.
  
   Environment.getStringObject(); 
   
3. Reflections:

   Reflections make static analyses almost unrealistic because each field
   can be accessed without unveiling static information, and each 
   method may be invoked without knowing receiver and targets statically.

   Current, the simulator warns the user by throwing a runtime exception
   that the analysis is not able to handle these features.

4. Serializations:

   The ObjectInputStream/ObjectOutputStream read/write fields of objects 
   by field IDs through native calls.
   
   The caller is warned by throwing an exception.

   java.io.ObjectInputStream
   java.io.ObjectOutputStream

5. Exceptions:

   Some native methods may throw exceptions. It is not considered right now.

6. Objects created with unknown types:

   There are a few native methods which may create objects for statically 
   unknown classes. In this situation, we suggest the class hierarchy add
   a least class type (which can be understood as NULL type). The least type
   won't affect the type information and virtual call resolution. But it
   does not block the flow information.

7. Other methods called by JVM directly:
   
   Non-trivial finilizer should be passed in all possible instantiations.
   There may be other methods called by VM directly, but which change 
   points information.