[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-dev] Pointcut shadows in newer releases?


I implemented pointcut rewriting and some associated optimisations in the AspectJ 5 codebase.

After resolution, pointcut expressions are rewritten in DNF, so that you have a tree with "or" branches at the top. All the child nodes of an "or" branch are then ordered so that the fastest to evaluate node is on the left hand side of the subtree, and the most expensive to evaluate node is on the RHS. Since all the children of any "or" will be 'anded' together some associated optimisations go on at this time such as calculating the set of join point kinds that can possibly be matched by the sub-_expression_. If no join point kinds can be matched, or the tree contains both A and !A then the whole _expression_ is replaced with 'false' (logical equivalent).  Once each or-subtree has been processed the "or"s themselves are also ordered left-to-right in evaluation expense order, and once again the set of possible join point kinds that can be matched are calculated.

Since DNF tends to replicate nodes, each pointcut _expression_ remembers the id of the last shadow it matched against, and the result of that match. Since the same pointcut _expression_ instance is used for each occurence in a pointcut, this means that matching is only done once. In fact, we walk through all the pointcuts known to the weaver and replace every "equal" pointcut _expression_ with the same ("==") _expression_ object. So we only evaluate any given _expression_ once for each shadow across the board for all shadow mungers. The information about the set of possible join points that could be matched by a pointcut _expression_ is used to fail very fast when matched against a shadow of a kind that cannot match. We also use this information to suppress shadow generation (and hence matching) altogether for certain types of shadows if we know that there is no shadow munger that could possibly match a join point kind (eg. no "set(.....)" pcds) in the type we are processing.

In general the cost of the matching process is totally dwarfed by the cost of actually weaving when a match does occur, so for many programs the speed-up is not that noticable - the rewriting was initially introduced for another reason altogether. However, in matching intensive applications - like a set of "enforcement" only aspects (deow) the speed-up can be significant. One project in IBM got about a 27x.

This stuff has been in the AspectJ codebase since AspectJ 5 M1.

In terms of really noticeable to end-users speed-up, Andy did some profiling of compilation via AJDT and fixed a bunch of little things (that we never would have guessed in a million years) that gave a real boost to compilation times. We'll continue to do more of that as we improve the AspectJ 5 codebase. These were outside of the weaving process though.

Regards, Adrian.

-- Adrian
Adrian_Colyer@xxxxxxxxxx



ervalerio@xxxxxxxxxx
Sent by: aspectj-dev-admin@xxxxxxxxxxx

02/03/2005 15:42

Please respond to
aspectj-dev@xxxxxxxxxxx

To
aspectj-dev@xxxxxxxxxxx
cc
Subject
[aspectj-dev] Pointcut shadows in newer releases?





Hello
i'm investigating how the weaving process is actually performed.
I'm reading "Advice weaving in aspectj" by Hilsdale and Hugunin, which relies
on 1.1 release.
Which are the differences with newer releases of aspectj compiler ?

I'm interested in particular inany difference with the 1.1 Fastmatch algorithm
and any other thing in newer releases.

Thanks to everyone

Valerio Schiavoni

__________________________________________________________________
Tiscali Adsl 3 Mega Flat con 3 MESI GRATIS!
Con Tiscali Adsl 3 Mega Flat navighi con la supervelocita'
a soli 29.95 euro al mese, senza limiti di tempo. E se attivi
entro il 15 Marzo, 3 MESI sono GRATIS!
Scopri come su http://abbonati.tiscali.it/adsl/



_______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-dev