Re: A proposal to change Soot [Long one]

[Patrick LAM <plam@sable.mcgill.ca>]

On Tue, 19 Aug 2003, Venkatesh Prasad Ranganath wrote:

> The above solution should suffice in cases where operations on a version
> is lumped together.  Say, loading/creation of all classes pertaining to
> untransformed system and transformed system happen at different times
> with no interleaving or overlaps.

>   However, things get messy in case the transformation use the
> untransformed system in bits and peices to create the transformed
> system.  This will lead to lots of singleton switches depending on the
> operations on the components of Soot.

As Ondrej mentioned recently on this list, this is a possible solution.
However, it fails completely for multithreading Soot.  I would think that
an acceptable solution should support running two Soots in different
threads.

Haveing a ThreadLocal, mutable Scene may be an acceptable compromise.

> A more elegant solution to this would be to make the entities
> "Environment" aware.  So, instead of the infamous G.v() or Scene.v()
> calls the entities would do a v() call on their environment. Hence, the
> environment would provide the necessary system instance information such
> as the Scene instance in which a class was created.  This is a big
> change.  For example, the to create a RefType one would need to provide
> the Environment in which the RefType should be created.  However, upon
> casual source browsing of Soot, it seems that such a change should be
> easy to instrument (don't frown, it's just a speculation).

If I understand correctly, you propose to add the Environment, as a
parameter, to every method call that requires it.  This would seem to make
it much more cumbersome to do things; is that the case?

>  From the point of view of the individual applications that are
> currently using Soot, the change can be done as an extension. The
> extension will be to enable support for an environment-based approach
> which can be used if needed.

I don't understand how you would do this.

> support and the Soot team welcomes these changes, I volunteer to take a
> first stab at injecting this support into Soot 2.0.1 (as available via
> the downloads page or probably the CVS version provided I get access to
> it) and others can contribute as things shape up.  Even before getting
> any closer to code or how we can accomplish this change, it would be
> wise to discuss about it in the Soot community.

Soot's subversion repository is at
https://svn.sable.mcgill.ca/soot/soot/trunk.  You can check out the
development version and hack on it as you'd like.

pat