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(); } } • Which code do aspects affect? • Code is affected by which aspects? ? ? aspect TraceB after(): execution (void B.m()){ System.out.println(“execution of B.m()”) } } aspect TraceA{ after(): call (void A.m()){ System.out.println(“ } }

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(); } } • Automated tool support can identify affected method declarations aspect TraceB after(): execution (void B.m()){ System.out.println(“execution of B.m()”) } } aspect TraceA{ after(): call (void A.m()){ System.out.println(“ } }

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(); } } • Automated tool support can identify affected method call sites aspect TraceB after(): execution (void B.m()){ System.out.println(“execution of B.m()”) } } aspect TraceA{ after(): call (void A.m()){ System.out.println(“ } }

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(); } } • Aspects depend on dynamic binding • Effects of dynamic binding not statically computable aspect TraceB after(): execution (void B.m()){ System.out.println(“execution of B.m()”) } } aspect TraceA{ after(): call (void A.m()){ System.out.println(“ } } >> call to A.m() >> call to A.m() >> execution of B.m() >>

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. Reflection Control Inspection Events 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. Reflection Control Inspection Events 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? Reflection Control Inspection Events 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 Revisited:Tracing 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(“ } } When does the match take place? OO event model insufficient! Detach message sent from method call!

18. Trace format for AspectJ advice

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