Towards a Standard Interface for Runtime Inspection in AOP Environments

1
Towards a Standard Interface for Runtime
Inspection in AOP Environments
Katharina Mehner and Awais Rashid

• OOPSLA Workshop on Tool for AOSD, Seattle,
  November 2002

2
Motivation

• During development and maintenance programmers
  need to develop an understanding of structure and
  behaviour
• Programmers cannot easily determine the effects
  of aspects
• Quantification Aspects apply to many places
• Obliviousness Components unaware of aspects
• Aspect interference

3
Example Dynamic binding
class A public void m() //do something

class B extends A public void m()
//override A.m()
class Application static void main(String
args) A a1 new A A a2 new B
a1.m() a2.m()
?
?
aspect TraceB after() execution (void B.m())
System.out.println(execution of B.m())
aspect TraceA after() call (void A.m())
System.out.println(

• Which code do aspects affect?
• Code is affected by which aspects?

4
Editor support (1)
class A public void m() //do something

class B extends A public void m()
//override A.m()
class Application static void main(String
args) A a1 new A A a2 new B
a1.m() a2.m()
aspect TraceB after() execution (void B.m())
System.out.println(execution of B.m())
aspect TraceA after() call (void A.m())
System.out.println(

• Automated tool support can identify affected
  method declarations

5
Editor support (2)
class A public void m() //do something

class B extends A public void m()
//override A.m()
class Application static void main(String
args) A a1 new A A a2 new B
a1.m() a2.m()
aspect TraceB after() execution (void B.m())
System.out.println(execution of B.m())
aspect TraceA after() call (void A.m())
System.out.println(

• Automated tool support can identify affected
  method call sites

6
Running the example
class A public void m() //do something

class B extends A public void m()
//override A.m()
class Application static void main(String
args) A a1 new A A a2 new B
a1.m() a2.m()
aspect TraceB after() execution (void B.m())
System.out.println(execution of B.m())
aspect TraceA after() call (void A.m())
System.out.println(

• Aspects depend on dynamic binding
• Effects of dynamic binding not statically
  computable

gtgt call to A.m() gtgt call to A.m() gtgt execution of
B.m() gtgt
7
Many more problems

• Aspect behaviour is highly dynamic
• Depending on dynamic binding
• Conditions on joinpoints evaluated at runtime
• Dynamic aspects
• Aspects introducing new join points
• Aspects changing inheritance structure
• Inter-Aspect relations
• Interference
• Dependencies
• Limitations for formal analysis
• Static analysis of dynamic binding NP-hard
• Similar results for all dynamic issues

8
Outline

• Requirements
• Proposed solution
• State-of-the-art runtime inspection
• Runtime inspection for AOP
• Example revisited

9
Requirements

• Problems are highly dynamic
• Get missing information from execution!
• Cumbersome and error prone without tool support
• Macros and printlines
• Forgetting statement and branches (sampling
  errors)
• Debuggers
• Only show one state at a time
• No history recording nor a complete picture
• Stepwise only is timeconsuming
• Automated Tracing
• Recording history
• Test case generation (not addressed here)
• Coverage by user chosen input error prone

10
Proposed solution Tool support

• Runtime information is essential
• Used by many different tools
• Debugging, Tracing, Monitoring,
• General instead of adhoc solution
• Standardization for
• Implementation/Architecture
• Control model
• Data format
• Debug information
• Visualizations

11
State-of-the-art runtime inspection

• Events
• Predefined list of observable events (program
  continues)
• Event records (limited information)
• Filters
• Inspection
• Entire state (only available if program stopped)
• No history recording

12
State-of-the-art runtime inspection

• Control
• Stop/continue on events, break-, watchpoints
• Step
• Stop/continue individual threads
• Record replay
• Reflection
• Separate API

13
What extensions are needed?
Runtime changes to aspect order
Extend granularity of execution steps
Cover aspect states
Aspect events

• Extensions for every layer of runtime inspection
• How to we determine
• New event types?
• State information needed?
• Execution granularity and break-/watchpoints?
• Base it on a general approach

14
A Generic AOP model

• Open issues
• Granularity of aspect event model
• Granularity of aspect state model
• Runtime perception influenced by implementation
  approaches
• Uniform Approach
• Based on Generic AOP model

15
Example Advice weaves

• Statics predefined event types, matches,
  predicates,
• Dynamics Chain of related actions
• Match
• Matched Event, Parameters
• Quantifying predicate (Pointcut)
• Condition evaluation
• List of triggered activities
• Order/Conflict Resolution
• Execution of activities
• Recursion Triggers new chains

16
Event model for advices

• Advices triggered by OO events
• Extend existing event record with chain
• Chain accessible indepently from OO events
• Create new events for actions in chain
• Trade-Off
• Conflict resolution
• results in order
• be more explicit
• Configurable events

17
Example RevisitedTracing Method Calls
class Application static void main(String
args) A a1 new A A a2 new B
a1.m() a2.m()
aspect TraceA after() call (void A.m())
System.out.println(
Time Event type Caller Callee Method/Advice Matched Event Advice List Pointcut Conditions
.
1 M_Entry main a1 A void m()
2 M_Exit main a1 A void m()
When does the match take place? OO event model
insufficient! Detach message sent from method
call!
18
Trace format for AspectJ advice
T Event type Caller Callee Method/Advice Matched Event Advice List Pointcut Conditions

3 JP_Match Ref 1,2 TraceA. after() call(void m()) After()call (void m()) -
4 Advice_Activ TraceA. after() call(void m())
5 Advice_Exec TraceA after()call (void m())
6 M_Entry TraceA Out println()
19
UML trace
20
Useful trace information

• Compare traces with static analysis
• Add partial information to editor
• Classification of runtime information

21
Conclusion

• Runtime information can improve understanding of
  aspects
• Adapt runtime inspection models from other areas
  of software development
• Make the right choices for extensions based on
  generic AOP model

22
The end