Re: [aspectj-dev] Pointcut shadows in newer releases?

[Adrian Colyer <adrian_colyer@xxxxxxxxxx>]

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