Slicing AspectJ Woven CodeSlicing AspectJ Woven Code

Luca CavallaroMattia Monga

Antonio Castaldo D'Ursi

Davide Balzarotti (balzarot@elet.polimi.it) 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 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∩ S

2=∅

A1A2

S1S2

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 Nodes

Time (in seconds)

236 0.64

511 1.05

1067 2.25

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