1. Optimizing AspectJ Pavel Avgustinov, Aske Simon Christensen, Laurie Hendren, Sascha Kuzins, Jennifer Lhotak, Ondrej Lhotak, Oege de Moor, Damien Sereni, Ganesh Sittampalam, Julian Tibble Oxford University University of Aarhus McGill University PLDI 2005 Presented by Geoff Hulette

2. What is AspectJ? Aspect-Oriented Programming (AOP) language extension for Java

3. What is AOP? AOP addresses cross-cutting concerns Examples: logging, debug traces, method- level security Goal: remove cross-cutting concerns from objects, put them in aspects

4. What is an Aspect? Join point: span of code in the execution of a program Pointcut: query that picks out join points Advice: code to execute at a join point

5. Why Optimize? Dynamic model  naïve compilers add considerable overhead Fortunately, a lot of advice can be compiled statically

6. Case 1: Around Advice Executes instead of a join point, but can transfer control back into the join point using proceed() Problem: how do you know where proceed should take you?

7. Standard Solution Closures: pass an object to the advice method with the right code and context “Inlining”: duplicate the advice method for each join point

8. ABC’s Solution Keep proceed method in the original class Call the advice method with IDs for the originating class and join point Sort it out with a switch statement

9. Results Code is 25% smaller, on average. Recursive execution times are much faster (3 to 6 times) when recursive advice is applied, about the same otherwise ABC is insensitive to recursive advice

10. Case 2: cflow Cflow(p): picks out join points in the control flow of p Example pointcut: cflow(call(bar())) && call(foo())

11. AJC’s Solution Create a stack for each cflow Where p becomes true, push context At join points, test if stack is non-empty

12. First the easy stuff Combine cflow stacks: cflow(call(a())) && call(b)|| cflow(call(a())) && call(c)  cflow(call(a())) && (call(b)||call(c)) Use counters instead of stacks, if possible Cache stacks/counters

13. Then the hard stuff Goal: classify instructions to make dynamic checks into static ones

14. Examples

15. MayCflow Instructions are in mayCflow(sh) if they may be in the scope of update shadow sh If a query is not in mayCflow, we can replace it with neverMatch

16. Compute MayFlow Begin with instructions in an update shadow (between push and pop) Add all instructions that might be called from within

17. MustCflow Instructions are in MustCflow(stack) if that instruction is always in that cflow Replace queries in set with alwaysMatch

18. Compute MustFlow Pre-compute a list of all statements within a cflow that have no dynamic queries Start with all statements Eliminate those that can be reached from entry points without passing through the pre-computed list

19. NecessaryShadows Set of update shadows whose effects may be observed, and whose effects are not duplicated Any update shadow not in this set can be eliminated

20. Compute NecessaryShadows The set of update shadows whose mayFlow sets contain no dynamic queries Also remove those that are in the mustflow of another update

21. Results Easy stuff led to biggest gains (up to 54x) Hard stuff helped too, but generally not much

22. Other Optimizations Static Joinpoint data Eliminate boxing/unboxing Other standard optimizations