Re: Changes from 1.2.4

["Stephen Andrew Neuendorffer" <neuendor@eecs.berkeley.edu>]

At 03:16 PM 9/14/2003 -0400, Ondrej Lhotak wrote:
> On Wed, Sep 10, 2003 at 08:46:59PM -0700, Stephen Andrew Neuendorffer wrote:
> > I'm finally getting around to upgrading to 2.0.1, but I've run into some
> > difficulties...
> >
> > It used to be that a transformer declared the valid options, which was
> > convenient for the rest of the world, if not for you guys, since it made a
> > transformer self contained...  Can this come back?
>
> The reason for this is historical, namely that some Transformers are
> repeated in different Transforms, and have different options in each
> one. Under the old system, there were default defaults, which were
> overridden by default options in the Transformer, which could be
> overridden by default options in the Transform, which were then further
> overridden by default options passed in from the pack, which were
> finally overridden by the options finally specified on the command line.
> We're trying to reduce the number of places where the set of options can
> be specified, to reduce confusion.
>
> It may be possible to somehow merge transform and transformer, and for
> the relatively rare case when a transformer appears in more than one
> transform, we could just have (possibly anonymous) subclasses of the
> transformer. But I think some people trying to reuse existing
> transformers might object to this strongly.

OK, I was thinking more about the declared options, and not the default 
options.
It seems that for a transformer, regardless of how many times it is in a 
transform, should
always have the same options declared, right?  This is especially important
since all of the options are now checked.  Allowing this information to be 
declared
inside the transformer means that transformers can be written correctly 
with the options interface
without modifying the xml files that declare the options...
Perhaps another approach would be to have a mechanism whereby the nifty xml 
files could be
used/extended without modifying the existing files.  (perhaps there is, but 
I didn't see one).

> > Also useful would be a set of required options that would be checked.
>
> You mean you want to add a phase that forces the user to specify
> options, rather than just accept the default values? This goes against
> the idea of being able to just run "java soot.Main Classname".

True.  Not a big deal, but it would be useful for my purposes..  I can get 
the same behavior other ways.

> > Have you guys considered using a hierarchy pattern for Packs?  Namely the
> > code below is obnoxious because it means that new toplevel packs cannot be
> > added...  This used to not be a problem, because I could put everything
> > into wjtp, but now that is tied to spark...
>
> How is wjtp tied to Spark? I don't understand.

It's not, but In order to turn on wjtp (where my transformations exist), I 
need -w, which also turns
on your whole-program transformations, so I need to have:
 -p wjop.smb off
 -p wjop.si off
 -p wjap.ra off
 -p cg off

as well.  I'd be happy to put them somewhere else, but I can't because of 
the next problem.


> We did consider a hierarchy of packs, but decided against it, again for
> historical reasons. There are still things that Soot does in between
> packs that are not standard packs and phases, and we were unable to
> agree on ways that this could be changed. Unfortunately, Soot is not
> just a list of passes that always get executed one after another; it
> takes various inputs and produces various outputs, taking possibly
> very different paths along the way. This means that it's not enough to
> just tell some root pack to "execute yourself and recursively all your
> subpacks".

This is unfortunate.  This makes it much more difficult for modifications to be
made.  The tricky code seems to be in runBodyPacks(), correct? would it 
possible to
move in this direction by having an extra hook in the code below (from 
PackManager):

    public void runPacks() {
        for(Iterator genericPacks = genericPackList().iterator(); 
genericPacks.hasNext();) {
           Pack pack = genericPacks.next();
           pack.apply();
        }
        if (Options.v().whole_program()) {
            runWholeProgramPacks();
        }
        preProcessDAVA();
        runBodyPacks( reachableClasses() );
    }


> Originally, Soot was only
> intra-procedural, and contained only BodyTransformers. For each method,
> all of the body transformers would be executed in sequence. Then
> everything associated with the method would be freed, and we would go
> onto the next method. With SceneTransformers, you cannot do that; you
> need to execute the SceneTransformers one after another on the whole
> Scene. Currently, we first execute all the SceneTransformers that are
> to be executed (if any), and then, for each method, for each
> BodyTransformer, we execute it. This means that if you are not doing a
> whole-program analysis (which many people don't), you don't need to have
> all of the intermediate representations of all the methods loaded at the
> same time; you can do one method at a time.

Makes sense...  The difficulty is that it is often useful to mix 
BodyTransformers
(such as for type inference) with SceneTransformers.  The adapter in my 
previous
email makes this simple.  If you would like to include it in Soot, feel free.

Thanks for your response...

Steve