Towards a Standard Interface for Runtime Inspection in

AOP Environments

OOPSLA Workshop on Tool for AOSD, Seattle, November 2002

Katharina Mehner and Awais Rashid

K. Mehner 2 Lancaster University

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

K. Mehner 3 Lancaster University

Example – Dynamic binding

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(); }}

class A{ public void m(){ //do something }}

aspect TraceA{ after(): call (void A.m()){ System.out.println(“ }}

aspect TraceB after(): execution (void B.m()){ System.out.println(“execution of B.m()”) }}

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

??

K. Mehner 4 Lancaster University

Editor support (1)

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(); }}

class A{ public void m(){ //do something }}

aspect TraceA{ after(): call (void A.m()){ System.out.println(“ }}

aspect TraceB after(): execution (void B.m()){ System.out.println(“execution of B.m()”) }}

• Automated tool support can identify affected method declarations

K. Mehner 5 Lancaster University

Editor support (2)

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(); }}

class A{ public void m(){ //do something }}

aspect TraceA{ after(): call (void A.m()){ System.out.println(“ }}

aspect TraceB after(): execution (void B.m()){ System.out.println(“execution of B.m()”) }}

• Automated tool support can identify affected method call sites

K. Mehner 6 Lancaster University

Running the example

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(); }}

class A{ public void m(){ //do something }}

aspect TraceA{ after(): call (void A.m()){ System.out.println(“ }}

aspect TraceB after(): execution (void B.m()){ System.out.println(“execution of B.m()”) }}

>> call to A.m()>> call to A.m()>> execution of B.m()>>

• Aspects depend on dynamic binding

• Effects of dynamic binding not statically computable

K. Mehner 7 Lancaster University

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

K. Mehner 8 Lancaster University

Outline

• Requirements

• Proposed solution

• State-of-the-art runtime inspection

• Runtime inspection for AOP

• Example revisited

K. Mehner 9 Lancaster University

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

K. Mehner 10 Lancaster University

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

K. Mehner 11 Lancaster University

Events

Inspection

Control

Reflection

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

K. Mehner 12 Lancaster University

Events

Inspection

Control

Reflection

State-of-the-art runtime inspection

• Control– Stop/continue on events, break-, watchpoints– Step– Stop/continue individual threads – Record & replay

• Reflection– Separate API

K. Mehner 13 Lancaster University

Events

Inspection

Control

Reflection

What extensions are needed?

Cover aspect states

Extend granularity of execution steps

Runtime changes to aspect order

• 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

Aspect events

K. Mehner 14 Lancaster University

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

K. Mehner 15 Lancaster University

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…

K. Mehner 16 Lancaster University

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

K. Mehner 17 Lancaster University

Example Revisited:Tracing Method Calls

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()

class Application{ static void main(String args[]){ A a1 = new A; A a2 = new B; a1.m(); a2.m(); }}

When does the match take place?OO event model insufficient! Detach message sent from method call!

aspect TraceA{ after(): call (void A.m()){ System.out.println(“ }}

K. Mehner 18 Lancaster University

Trace format for AspectJ adviceT Event type Caller Callee Method/

AdviceMatched 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()

K. Mehner 19 Lancaster University

UML tracea2B

a1A

System.outaspect TraceA aspect TraceBAppl

4.1: println("call to A.m()")

2.1: println("call to A.m()")

5: after a2.m()

4: after a2.m()

3: m():void

1: m():void

2: after: a1.m

5.1: println("execution of B.m()")

<join point> a1.m <matches> {TraceA.after():call(void A.m())}<join point> a1.m <activates> TraceA.after():call(void A.m())

<join point> a2.m <matches> {TraceA.after():call(void A.m()),TraceB.after():execution(void B.m()}}<join point> a2.m <activates> TraceA.after():call(void A.m())<join point> a2.m <activates> TraceB.after():execution(void B.m())

K. Mehner 20 Lancaster University

Useful trace information

• Compare traces with static analysis

• Add partial information to editor

• Classification of runtime information

K. Mehner 21 Lancaster University

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

K. Mehner 22 Lancaster University

The end