[Soot-list] Instrumenting JRE classes using Soot
bodden at st.informatik.tu-darmstadt.de
Mon Apr 26 02:58:56 EDT 2010
> It seems that the play-out agent in TamiFlex is a "class-interception"
> tool which keeps
> track of all potentially loaded classes of a specific Java application.
> The the user
> could use any static analysis tool to perform *offline* bytecode
> instrumentation. After so,
> new classes after transformation are saved to disk and will be loaded by
> the "play-in agent" to replace the
> original class (loaded from cloud). right?
Generally that is correct. Having said that, you can also use just the
play-in agent in isolation, without doing a play-out before. Play-out
is only necessary if you have trouble getting your hands on all the
classes (and reflective calls, but that's a different topic) that an
application performs. If you already have access to all those classes
then you can just process these classes with Soot and point the
play-in agent to Soot's output directory. When you then run the
application, the agent will cause the application to load its classes
from this folder instead of where it would normally load its classes
In any case, for your use case (adding profiling statements) TamiFlex
should work just fine. After all, this appears to be an offline-only
> So it seems that we need at least two runs to replace certain classes,
> one is for "play-out"
> agent to do offline instrumentation, and the other run is to reload the
> transformed class.
> I am wondering could TamiFlex do "online instrumentation" for certain
> classes, that is:
> "play-out" and "play-in" agents work in a pipeline manner (without
> writing classes to
> disk and read that back)? I think that might be much more useful.
In general this should be possible. We do not yet support this but it
seems worthwhile thinking about for a future release. Would you be
interested in modifying classes only at load time, i.e.,
application-startup time or even later during the application's
More information about the Soot-list