[Soot-list] Instrumenting JRE classes using Soot

Sai Zhang racezhang at gmail.com
Mon Apr 26 01:31:01 EDT 2010


Hi Eric:

Thanks for your message.

I have browsed the document of TamiFlex, and  am a bit confused on several
points:

    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?

    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.

    Thanks

-Sai Zhang
http://cs.washington.edu/homes/szhang




On Thu, Apr 22, 2010 at 12:19 AM, Eric Bodden <
bodden at st.informatik.tu-darmstadt.de> wrote:

> Hello Sai.
>
> Have you looked at TamiFlex? http://tamiflex.googlecode.com/
>
> Tamiflex is a pair of Java agents, a "play-out agent" and a "play-in
> agent". The latter can be used to replace classes that the VM is about
> to load with (e.g. sootified) classes from a given directory. You can
> also use it to replace classes from the JRE. The beauty of this is
> that you can leave rt.jar untouched.
>
> Eric
>
> --
> Dr. Eric Bodden
> Software Technology Group, Technische Universität Darmstadt, Germany
> Tel: +49 6151 16-5478    Fax: +49 6151 16-5410
> Mailing Address: S2|02 A209, Hochschulstraße 10, 64289 Darmstadt
>
>
>
> On 21 April 2010 19:31, Sai Zhang <racezhang at gmail.com> wrote:
> >
> > Hi all:
> >
> > For some reason, I need to instrument some jre classes (residing in
> rt.jar)
> > for doing
> > dynamic analysis using Soot. It is a pretty simple analysis, and will
> never
> > touch
> > some "dangerous" classes like java.lang.Object, java.lang.Class. etc. I
> can
> > foresee that
> > all classes I need to instrument are inside java.util package.
> >
> > For instance, what I am doing is to add "profiling code" before and after
> > each method call like:
> >
> > java.util.Vector..
> >
> > int size() {
> >     Tracer.startCall("size()");
> >
> >     //the method body
> >
> >     Tracer.endCall("size()");
> > }
> >
> > //Tracer is a simple class to keep track of traces
> >
> >
> > Implementing such analysis is not hard, but I am wondering is there any
> > convenient way to
> > "deploy" such  changes. Normally, we unzip the rt.jar, do
> instrumentation,
> > and get a set of instrumented classes.
> > We can either:
> > (1) pack the instrumented classes into the rt.jar (but that could be a
> bit
> > problematic, at least on
> > my laptop. an exception is thrown when initializing the JVM, it can not
> find
> > the class Tracer!!!)
> > (2) reset the BootClasspath to point to the instrumented classes dir.
> >
> > For me, only (2) works! I am curious what is the best practice to use
> Soot
> > for jre class instrumentation?
> >
> > thanks
> >
> >
> > --Sai Zhang
> >
> > _______________________________________________
> > Soot-list mailing list
> > Soot-list at sable.mcgill.ca
> > http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20100425/8cc19073/attachment.html 


More information about the Soot-list mailing list