RE: RE: [abc-users] Using abc for instrumentation

From: Eric Bodden <>
Date: Tue May 23 2006 - 02:47:45 BST


> Thank you for your prompt and detailed reply! My mailbox
> didn't receive a copy of your email, so I can't send this
> reply to the mailing list.

I don't quite see what you mean by "your mailbox did not receive a copy"
but I will forward this to the list.

> > This really depends on the kind of instrumentation you
> want. Probably
> > it would even be enough to write a simple aspect to retrieve the
> > information you want.
> >
> In fact, I thought about using aspects to do instrumentation,
> but I don't think it's suitable for my project. Since I need
> to produce execution trace at statement-level, but AspectJ
> joinpoint model isn't fine enough to achieve such
> granularity; besides, I need some other information, which
> can't be easily (if not impossibly) obtained this way.

Ok, in this case you cannot do it with an aspect cause we have no
statement level joinpoints (not yet - I seem to recall having heard
people working on this).

> > If not, generally I can certainly say "yes", abc is a good tool to
> > achive those kind of things. The only question is if it is not a
> > little overkill to do so. There might be easier ways, e.g.
> using Soot
> > (which abc is built on top of).
> >
> If I understand correctly, Soot works with pure Java
> programs, and the information about aspect-related constructs
> is missing from Soot, but I need that information, for
> example, I need to distinguish advice from Java methods.

You are right, Soot works on pure Java. Since any AspectJ program is
compiled to valid standard Java bytecode, it's no problem to process it
with Soot. However, as you note, you cannot consistently identify
constructs induced by aspects. When abc generates bytecode it usually
follows certain naming conventions for generated advice methods, so that
you could use this for identifying advice, but it would obviously not be
100% consistent.

> > I would say that it does only make sense to use abc if you have a
> > special purpose input language, e.g. a language that defines your
> > instrumentation. An example of this is J-LO
> > (, which is built on top of abc.
> >
> I'll take a look at it later on.
> > If you have rather a *fixed* kind of instrumentation that
> you want to
> > apply different programs, then you might be better off with Soot,
> > which allows you to instrument programs using a
> BodyTransformer. (see
> > the two "profiling" tutorials on
> >
> > <> )
> >
> > So what kind of information do you want to retrieve? Is it
> static or
> > dynamic? Is it AspectJ specific or can it be inferred from Java
> > bytecode?
> >
> What I'm trying to create is an execution tracer for AspectJ
> programs which can work at different granularities including
> statement-level, method/advice-levle, and class/aspect-level.
> The input for the tracer is source code of an AspectJ
> program, while the output is a sequence of statements of
> interest in the order of their execution. Such tracer is
> created to support further analysis of an AspectJ program's
> dynamic behavior. For example, we can perform a dynamic
> slicing for an AspectJ program based on the trace information.

Ok in this case you maybe really want to use abc, I guess. How you
extend abc for your purposes depends on the term "statement of interest"
then, I guess. In particular it would be good to know whether you want
to identify such statements based on source code properties or bytecode
properties. Depending on this, you might rather want to rewrite the AST
of the source representation or the Jimple code of the bytecode
representation respectively in order to add your instrumentation code.
Both is certainly possible with abc.

Received on Tue May 23 02:47:58 2006

This archive was generated by hypermail 2.1.8 : Wed May 24 2006 - 21:30:06 BST