Transcript [Slides, powerpoint]

Slicing AspectJ Woven Code
Davide Balzarotti ([email protected]) Politecnico di Milano
Luca Cavallaro
Mattia Monga
Antonio Castaldo D'Ursi
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
2
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
3
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
4
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=∅
A1
A2
S2
S1
5
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
6
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
7
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
8
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
9
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();
}
}
10
public class T{
int temperature;
public void set_temp(int t){
//....
this.temperature = t;
//...
}
public aspect LockAspect {
public void T.get_lock(){
System.out.println("Lock aquired");
}
public void T.release_lock(){
System.out.println("Lock released");
}
public void shutdown(){
...
}
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();
}
}
Results

The slice computed using TInvariant as slicing criterion does not
contain any line from LockAspect code
Non-interference is guaranteed

The slice computed using LockAspect as slicing criterion contains
a line from the TInvariant advice code
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

Also a real interference is not a proof that there is a problem !!!
12
Results (graphs)
System Dependence Graph:
Tulip format
236 Nodes
650 Edges
vcg format
13
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.
14
Scalability

Cost of SDG construction
Number of Nodes

Time (in seconds)
236
0.64
511
1.05
1067
2.25
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
15
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
16