1 / 22

Optimizing AspectJ

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.

kanoa
Download Presentation

Optimizing AspectJ

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related