Slicing AspectJ Woven Code

1. Slicing AspectJ Woven Code Davide Balzarotti(balzarot@elet.polimi.it) Politecnico di Milano Luca Cavallaro Mattia Monga Antonio Castaldo D'Ursi

2. Motivation • AOP is becoming more and more popular since • It allows to better organize the code modularizing cross-cutting concerns • It is easier to develop small and isolated code unit than big and complex programs • Some points are still unclear… How difficult is to maintain/improve aspect oriented code? • It is not clear how a change in an aspect can affect the whole system • Adding a new aspect can violate some system properties Are aspects real unit of comprehension or just syntactic sugar ? • In order to truly understand the behavior of base code one must read the code of every aspects

3. Aspect Interaction • An interaction occurs every time an aspect can affect the behavior of another aspect. • It is very common when multiple aspects apply to the same program. • It is not always a bad thing (it could be a required behavior). • Developers must be aware of possible aspects interactions • Sometimes it is very hard to find out interferences reading the code.(An aspect can modify the value of a field, that change the execution path, causing the change of another field value…. eventually affecting the behavior of another aspect) • It would be nice to have a tool to check aspects interaction at compile time

4. Program Slicing (in a nutshell) • Informally, a slice consists in all the program statements that may influence a given set of statements (called slicing criterion). • Introduced by Weiser in the ’80 for procedural programming • Extended to Object Oriented code by Larsen & Harrold in ’96 • Interprocedural slices can be computed solving a reachability problem on the program System Dependence Graph (SDG) • Problems: • Tons of good papers, very few running code • Existing solutions cannot be applied as they are to aspect oriented code

5. A2 A1 S1 S2 Program Slicing for Aspect Interaction Analysis • The slice associated to an aspect is a reduced model of the whole system as far as concern aspect code influence • Let A1 and A2 be two aspects and S1 and S2 the corresponding backward slices (computed using A1 and A2 as slicing criteria) A1 does not interfere with A2 if: A1∩ S2=∅

6. A different approach • Rinard, Salcianu, Bugrara. (FSE end of 2004) • Advice classification: augmentation, narrowing, replacement, combination • They use scope to classify the interactions between aspect and method: • Orthogonal (disjoint fields) • Independent (no read/write) • Observation (advice read, method write) • Actuation (advice write, method read) • Interference (both write the same fields) • Implementation • Pointer and escape analysis • Only method execution and method call join point

7. Slicing AOP • Zhao (2002) • Target language: AspectJ • Aspect oriented SDG (ASDG). Special constructs for advice, introduction… • No dynamic pointcuts and wildcards • Blair & Monga (2003) • Target language: AspectJ • Translate each aspect in a conjugated class, then it applies object oriented algorithms without any modifications • No introductions, no whole program analysis • Problems: • Quite limited support of many AspectJ features • Hard to implement in a working tool

8. Bytecode Slicing Let all the dirty work to the AspectJ compiler • Build the System Dependence Graph analyzing the Java byte-code • Apply program slicing techniques using each aspect as the slicing criterion • Map back the slices nodes to the original classes/aspects Advantages • AspectJ takes care of translating aspects in classes (we implicitly support all its features) • No changes are needed if AspectJ introduces a new functionality Disadvantages • Some details is lost in the weaving process (for instance a hierarchy change) • If AspectJ change its aspects translation approach, we may need to modify our tool

9. Process • Compile the code using AspectJ (or take a precompiled bytecode) • Build the callgraph (soot) • Analyze each procedure (control dependence, data flow, aliases) • Connect everything together in the SDG • For each aspect: • Select all the aspect’s nodes as slicing criterion • Calculate a backward static slice • Map back the resulting nodes to the original classes/aspects

10. public aspect TInvariant { before(T t, int newval): set(int T.temperature) && args(newval) && target(t) { if (newval > 100) t.shutdown(); } } Example public class T{ int temperature; public void set_temp(int t){ //.... this.temperature = t; //... } public void shutdown(){ ... } }

11. public aspect LockAspect { public void T.get_lock(){ System.out.println("Lock aquired"); } public void T.release_lock(){ System.out.println("Lock released"); } before(T t): target(t) && (call(void set_temp(int))){ t.get_lock(); } after(T t): target(t) && (call(void set_temp(int))){ t.release_lock(); } before(T t): target(t) && (call(void shutdown())){ t.get_lock(); } after(T t): target(t) && (call(void shutdown())) { t.release_lock(); } } public class T{ int temperature; public void set_temp(int t){ //.... this.temperature = t; //... } public void shutdown(){ ... } } ?

12. Non-interference is guaranteed TInvariant may affect the behavior of LockAspect Note: Since the minimum slice is incomputable, the tool can find spurious interaction due to some unnecessary nodes Results • The slice computed using TInvariant as slicing criterion does not contain any line from LockAspect code • The slice computed using LockAspect as slicing criterion contains a line from the TInvariant advice code • Also a real interference is not a proof that there is a problem !!!

13. Tulip format vcg format Results (graphs) System Dependence Graph: 236 Nodes 650 Edges

14. Limitation The current prototype has the following limitations: • No arrays • No exception handling • No inner classes • No static members • No recursive calls • No multithread • No inter-procedural aliases.

15. Scalability • Cost of SDG construction • Slicing Cost • A slice is performed by two traversals of the SDG. The cost of each traversal is linear on the size of the graph • In our example, the slicer algorithm took only 6 ms

16. Final Considerations • Static analysis seems a promising technique to help developers reasoning about aspects composition • A proper use of metadata annotations (Java 1.5+) by AspectJ compiler might make the mapping phase more precise and less implementation dependent • We are currently working to remove most of the limitations in order to survey quantitatively the modularity and evolvability of real world AspectJ program