[aosd-discuss] the pcflow pointcut

[Hidehiko Masuhara]

Hi,

To make discussion concrete, I'm going to quote an example in the
Gergor's keynote talk at AOSD.03
(http://www.cs.ubc.ca/~gregor/papers/kiczales-aosd-2003.ppt, page 32):

| pointcut* displayState():
|     pcflow(execution(void FigureElement+.draw())
|     && get(* FigElt+.*);
| after set(<displayState()>) (): {
|   Display.update();
| }

I believe that the example relies on two functions: (1) static
approximation of control flow as pointed out by Eric, and (2)
extraction of information from the approximated join points, which is
denoted by the < > operator.  So the above example can be read like:

 - displayState() approximates get join points from FigElt subclasses
   under the control flow of draw execution of FigureElement
   subclasses;

 - <displayState()> extracts the field signatures from the
   approximated join points by displayState(); hence

 - set(<displayState()>) matches set join points to those extracted
   fields.

I guess that the static optimization techniques Eric mentioned would
probably give the same information that pcflow ought to do, but we
still would need (2) in the language in order to realize (my) expected
semantics.

You can find an implementation of pcflow that is restricted to the
combination of get and set join points in the following paper:

T. Aotani and H. Masuhara, SCoPE: an AspectJ compiler for supporting
user-defined analysis-based pointcuts, In AOSD.07, pp.161-172.
http://doi.acm.org/10.1145/1218563.1218582

Regards,

Hidehiko
--
Hidehiko Masuhara
http://www.graco.c.u-tokyo.ac.jp/~masuhara/


2007/9/15, Eric Bodden <eric.bodden at mail.mcgill.ca>:
> Hi.
>
> As far as I know, pcflow was meant to be a predictive (i.e. static!)
> approximation of cflow, the idea being that it can be statically
> evaluated and hence may be more efficient (please correct me if I am
> wrong). So for a pcflow pointcut to be implemented corrrectly, if
> cflow(p) matches a joinpoint j, then pcflow(p) must match at the
> joinpoint shadow of j.
>
> If my definition above is correct and complete (where was this
> originally coming from again?) then I believe that the concept of
> pcflow has actually become somewhat obsolete because there exist
> static optimization techniques that implement exactly that predictive
> approximation as optimization for the "real" cflow pointcut:
>
> Avgustinov, P., Christensen, A. S., Hendren, L., Kuzins, S., Lhota'k,
> J., Lhota'k, O., de Moor, O., Sereni, D., Sittampalam, G., and Tibble,
> J. 2005. Optimising AspectJ. In Proceedings of the 2005 ACM SIGPLAN
> Conference on Programming Language Design and Implementation (Chicago,
> IL, USA, June 12 - 15, 2005). PLDI '05. ACM Press, New York, NY,
> 117-128. DOI= http://doi.acm.org/10.1145/1065010.1065026
>
> Hope that helps,
> Eric
>
> On 14/09/2007, dm_alhad at alcor.concordia.ca <dm_alhad at alcor.concordia.ca> wrote:
> >
> > Hi,
> > do you know what advantages the pcflow (predicted control flow) pointcut have
> > over the cflow (control flow) pointcut?
> > and are there join points that match one of them but don't match the other?
> > More precisely, if we have one pointcut p and we write pcflow(p) and cflow(p),
> > are they have different join points satisfying them or similar ones?
> > Finally, do u thing the pcflow can be programmed or not?
> > Dima
> >
> >
> > _______________________________________________
> > discuss mailing list    -    discuss at aosd.net
> >
> > To unsubscribe and change options, go to:
> > http://aosd.net/mailman/listinfo/discuss_aosd.net
> >
> > Check out the AOSD.net Wiki: http://aosd.net/wiki
> >
>
>
> --
> Eric Bodden
> Sable Research Group
> McGill University, Montre'al, Canada
>
> _______________________________________________
> discuss mailing list    -    discuss at aosd.net
>
> To unsubscribe and change options, go to:
> http://aosd.net/mailman/listinfo/discuss_aosd.net
>
> Check out the AOSD.net Wiki: http://aosd.net/wiki
>