Slicing AspectJ Woven Code Luca Cavallaro Mattia Monga Antonio Castaldo D'Ursi Davide Balzarotti Politecnico di Milano

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 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 A 1 and A 2 be two aspects and S 1 and S 2 the corresponding backward slices (computed using A 1 and A 2 as slicing criteria) A 1 does not interfere with A 2 if: A 1 ∩ S 2 = ∅ A1 A2 S1 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 Example public class T{ int temperature; public void set_temp(int t){ //.... this.temperature = t; //... } public void shutdown(){... } public aspect TInvariant { before(T t, int newval): set(int T.temperature) && args(newval) && target(t) { if (newval > 100) t.shutdown(); }

public class T{ int temperature; public void set_temp(int t){ //.... this.temperature = t; //... } public void shutdown(){... } 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(); }

12 Results  The slice computed using TInvariant as slicing criterion does not contain any line from LockAspect code 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  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 Results (graphs) System Dependence Graph: 236 Nodes 650 Edges vcg format Tulip format

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

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 Number of NodesTime (in seconds)

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