[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A proposal to change Soot [Long one]
On Tue, Aug 19, 2003 at 08:23:55PM -0500, Venkatesh Prasad Ranganath wrote:
> I propose the following simple solution to avoid customized distributions of Soot. The solution would be to add a new set
> method (the code follows) that enables the application to switch the singleton instance.
>
> public static G set(G soot) {
> G result = instance;
> instance = soot;
> return result;
> }
I have no problem with this, especially since you volunteered to
implement it. It there anything to it other than adding the above four
lines?
> 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).
> 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.
Let's consider the possible alternatives. I am aware of the following
ones:
1) Just do what you suggested above, and allow G.instance to be changed.
The disadvantage of this is that you may have to change it often, as you
point out, and this makes your code cumbersome. However, you could make
your own SootEnvironment, which has a G, and has wrapper methods for all
the things that you intend to call in Soot. These wrapper methods set
G.instance, and call the appropriate method. So then your code would
just look like:
SootInstance s1 = new SootInstance();
SootInstance s2 = new SootInstance();
s1.loadClassAndSupport("java.lang.Object");
s2.loadClassAndSupport("java.lang.Object");
Perhaps such a SootInstance class should be maintained as part of Soot,
rather than everyone writing their own. But people could subclass it to
add their own methods. Perhaps something using a factory would be best,
so that these subclasses would get automatically instantiated...
2) Pass around an "Environment" to everywhere it's needed. G was
intended to be such an Environment, but a new class could be created
instead if people prefer. This G would have to be passed to every part
of Soot that currently calls G.v(). I haven't done any sort of analysis
to determine how many methods would end up having to have G passed into
them, but I suspect it's a lot. This means it would cause a lot of
clutter. Furthermore, it would make Soot more difficult to extend: what
if you need a G somewhere, but it hasn't been passed down there? You
need to follow the whole call graph looking for all callers of the
current method, and pass it down.
3) Get rid of this whole environment/G thing altogether, and re-design
Soot so that all the bits and pieces have references to each other. For
example, each Unit would have a reference back to its Body, which would
have a reference to its SootMethod, which would have a reference back to
its SootClass, which would have a reference back to its Scene. This is
probably cleanest, but a lot of work. Someone would have to volunteer to
do it (and it wouldn't be me). It might make Soot easier to work with in
general, since you would know which method each statement was from. It
might also have a non-trivial performance impact, since we would be
adding at least one field to pretty much every object, and there are
lots of little objects all over the place.
An additional consideration is thread-safety. Someone might come someday
and want to run different instances of Soot on different threads. I
think options 2) or 3) could do this, and 1) could be modified to do
this using ThreadLocal. I could be wrong.
Both 2) and 3) might significantly break existing code that uses Soot,
in ways that may be a lot of work to fix. 1) shouldn't break anything.
There may be other options than these 3. Anyone who sees them, please
suggest them.
My personal preference is for option 1, possibly with the ThreadLocal
thing, mainly because it is the least invasive. But I'm biased, because
I have no personal need for this feature.
> This can have a big effect on the use of Soot in Eclipse because as users of Eclipse would be interested in program
> transformations available in Eclipse, the user would also be interested in ways to visualize the transformation and it's result.
>
> Well, I have put forth the proposal for review by the Soot community. In case, there are a bunch of people wanting such
> 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.
Read-only access to the Subversion repository is publicly available.
See http://svn.sable.mcgill.ca/
Subversion makes it very easy to create a patch, by simply typing:
svn diff > patch
If you make such a patch of something you think should be included in
Soot, and you don't have write access to the repository, you can send
the patch to the soot-list, and if everybody likes it, someone with
write access can commit it. (If the patch is long, please don't send
it out on the mailing list; just put it on the web somewhere and send a
link to it. Of course, the shorter the patch, the more likely it is to
be committed.)
Ondrej
>
> waiting for reply,
>
> --
>
> Venkatesh Prasad Ranganath,
> Dept. Computing and Information Science,
> Kansas State University, US.
> web: http://www.cis.ksu.edu/~rvprasad
>