[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-dev] Aspect reentrancy
|
Hi Eric,
You're right there are all sorts of problems associated with
if-pointcuts, but I don't agree with your proposed solution.
The intended semantics of AspectJ is that pointcut matching
never introduces new joinpoints: the semantic model is as in
Mitchell Wand, Gregor Kiczales, Christopher Dutchyn: A semantics for
advice and dynamic join points in aspect-oriented programming. ACM Trans.
Program. Lang. Syst. 26(5): 890-910 (2004)
According to that view, having an "if" in a pointcut is very
different from having it in an advice body. As you rightly
point out, that's not what ajc and abc implement, for efficiency
reasons, as otherwise the compiler would need to check whether
any joinpoint is in the cflow of an if-pointcut evaluation.
There are lots of other difficulties that arise from having
arbitrary Java expressions in if pointcuts, see for instance
https://bugs.eclipse.org/bugs/show_bug.cgi?id=61569
Personally I think the right solution would be to forbid
complex expressions in if-pointcuts.
I do not think your proposal of making ifs in advice and in
pointcuts equivalent is a good plan. For one thing, partial
evaluation of pointcut matching will have to be scrapped,
disabling almost all compiler optimisations for AspectJ.
For instance you could add "if(0 !=1)" to your example
pointcut. Now under your semantics, I would still have to
generate the joinpoint for the other if, or would you
make it nondeterministic whether that joinpoint occurs
or not?
Cheers,
-Oege
On Sun, 13 Apr 2008, Eric Tanter wrote:
Hi,
As part of a study I am doing on cases of aspect reentrancy and how to deal
with them, I came across something that seem to be a flaw in the language
semantics of AspectJ, at least as implemented by ajc and abc. (I assume abc
developers are also reading this list)
By aspect reentrancy, I mean when an aspect matches a join point as part of
the execution of an already-matched base program join point (eg. matching a
recursive call), of its pointcuts, or of its advice.
For the first case, base-triggered reentrancy, people have learnt to use
!cflowbelow(pc()).
For the case of advice-triggered reentrancy, people can use things like
!cflow(within(A)) and !cflow(adviceexecution()...).
The strange case is pointcut-triggered reentrancy, that can occur as a
consequence of the evaluation of an if pointcut. Consider the following
example:
public aspect Tracing {
before(Point p) : execution(* Point.*(..)) && this(p)
&& if(p.getX() < 0) {
i> System.out.println("hola");
}
}
It turns out that this simple aspect always leads to an infinite loop. I
could not find a way to specify that the execution of getX caused by the if
pointcut be ignored.
!cflow(within(Tracing)) does not work, etc.
As far as I could find, and we have discussed that with Eric Bodden as well
in the past days, the only solution for the above Tracing aspect to work is
to move the if pointcut into an if condition in the advice. Or are we missing
something?
The crux of the problem is that both abc and ajc decide to hide all the join
points that are _lexically_ in the if pointcut, but not those that are in the
_cflow_ of the if pointcut.
This semantics seems flawed first because it hides join points that are part
of the program execution (what if I have an aspect that controls calls to
Point getters? it will never be aware that such calls are performed by
Tracing); and second because it does not make it possible to avoid
pointcut-triggered reentrancy: because the call to getX above is hidden, I
cannot discriminate the execution of getX based on the cflow relation to
getX...
In any case it seems that the semantics of an aspect should not be changed by
moving a test from an if pointcut to the advice.
I'd be happy to know what you think of this problem, in particular if I'm
missing a really good reason of why things are the way they are, or that a
Tracing aspect as defined above is a bad idea.
Regards,
-- Éric
PS: I have worked on a detailed analysis of these issues, as well as on a
concrete proposal to control aspect reentrancy at a much nicer level of
abstraction (IMHO).
An online version of the proposal is available at:
http://www.dcc.uchile.cl/~etanter/reentrancy/main.html
Reactions and comments are very
welcome._______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-dev
