comments on Soot 'bottlenecks'

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

I'm going to reply to some of the slides in John's presentation about
benchmarking Soot.

Computing LocalDefs is definitely slow.  There should be a lot of
redundant work going on here.  In particular, one quick hack may be the
following: we can try to compute a signature on the Body and, in the
absence of changes, we can cache the old LocalDefs and re-use it
again.  LocalDefs computes the reaching definitions on Jimple.

A more efficient SimpleLocalDefs implementation might also help.  This
would be a good opportunity for anyone who wants to learn more about
Soot.  The implementation currently in place is highly naive, and could
possibly be sped up.  I don't know.  Also, it would be good if a
transformation kept the LocalDefs up to date when it modifies things, but
that's complicated.

The aggregation phase refers to removing obvious bogosity from the
generated Jimple code.  In particular, it's doing the same thing that we
describe in the CC2000 paper in the Grimp part, except that only
expressions which are valid Jimple are created (so these have to be
three-address instructions).  I suspect that most of the time here is in
collecting LocalDefs, but this would require more profiling.

I recently patched the scanner for jasmin (it's in jasmin 1.1-sable), but
the changes would probably make things slower, not faster.  Fortunately,
jasmin only runs at the end, so the memory allocated there doesn't affect
the rest of the program.

pat