Presentation is loading. Please wait.

Presentation is loading. Please wait.

Virtual Support for Dynamic Join Points C. Bockisch, M. Haupt, M. Mezini, K. Ostermann Presented by Itai Sharon

Similar presentations


Presentation on theme: "Virtual Support for Dynamic Join Points C. Bockisch, M. Haupt, M. Mezini, K. Ostermann Presented by Itai Sharon"— Presentation transcript:

1 Virtual Support for Dynamic Join Points C. Bockisch, M. Haupt, M. Mezini, K. Ostermann Presented by Itai Sharon (itaish@cs.technion.ac.il)

2 2 Agenda  Classification of crosscuts  Handling dynamic crosscuts  Steamloom and support for aspects on VM level  Evaluation  Related work

3 3 Terms  Join Point well defined place in the structure or execution where additional behavior can be attached  Pointcut Designator (PCD) Description of a set of join points and their values  Crosscut set of related join points defined by a PCD  Weaving the process of composing core functionality modules with aspects, thereby yielding a working system

4 4 Crosscuts  Code level crosscuts pointcuts that may directly be mapped to locations in the program code. e.g. “whenever method x is called”.  Dynamic corsscuts Pointcuts that emerge depending on the dynamics of the program e.g. “whenever exception y occurs”

5 5 Dynamic Crosscuts  Statically bound dynamic crosscuts pointcuts for which it is possible to statically determine a set of potentially affected code. e.g. “whenever method x is called in the control flow of y”.  Unbound dynamic crosscuts pointcuts whose correspondence to code locations cannot be restricted in a reasonable way before run time.

6 6 Quiz  Whenever foo() is called from bar()  Whenever foo() is called from cflow(bar())  Whenever x is called where x is a method obtained from the user Unbound dynamic crosscut Code-level crosscut Statically bound dynamic crosscut

7 7 Dynamic Crosscuts Support  For statically bound dynamic crosscuts:  instrument the set of potentially affected code locations with dynamic checks  For unbound dynamic crosscuts:  Same as for the statically bound dynamic crosscuts... Or  Programmatic aspect deployment  Fluid code, using just-in-time (JIT) compilation

8 8 Programmatic Aspect Deployment  An aspect has to be deployed for its pointcuts and advice to take effect  Fits unbound dynamic crosscuts better than the (too) general approach used in languages like AspectJ.  First implemented in C AESAR : deploy(anAspectInstance) {aBlock} deploy public class AnAspect {...

9 9 The Fibonacci class class TestApp { public void m1(int n) {fibstart(n);} public void m2(int n) {fibstart(n);} public void fibstart(int n) {fib(n);} public int fib(int k) { return (k>1) ? fib(k-1)+fib(k-2) : k; } Fib start m1 m2 fib

10 10 Fib start m1 m2 fib Counting Calls to fib() via m2() (a la AspectJ) public aspect FibonacciAspect { private int ctr = -1; pointcut m2cf() : cflow(call(void TestApp.m2(int))); before() : execution(void TestApp.fibstart(int)) && m2cf() { ctr = 0;} after() : execution(void TestApp.fibstart(int)) && m2cf() {System.out.println(ctr);} before () : execution(void TestApp.fib (int)) && m2cf() { ctr++;} }

11 11 Fib start m1 m2 fib Counting Calls to fib() via m2() (a la C AESAR ) public class FibonacciAspect { private int ctr = -1; before() : execution(void TestApp.fibstart(int)) { ctr = 0;} after() : execution(void TestApp.fibstart(int)) {System.out.println(ctr);} before () : execution(void TestApp.fib(int)) && m2cf() { ctr++;} } deploy public class DeploymentAspect { around() : call(void TestApp.m2(int)) { deploy new (FibonacciAspect()) {proceed();} }

12 12 Drawbacks of Pre-Runtime invasive Weaving  Impedance Mismatch  code loses its original modular structure  Pointcuts are implemented as dynamic checks in the set of potentially affected joinpoints  advices are regular Java classes (AspectJ)  Debugging and profiling are harder  Separate compilation is impossible  Expensive  both in terms of space and execution time  Cure: aspects support at VM level

13 13 Just In Time Compilation (JIT)  Get intermediate language code, compile it at runtime on the target machine to native machine code  Code remains platform independent but executes fast  Per-machine/user optimizations are possible  Rather then optimizing the code, optimize the compiler  Used in commercial compilers such as Sun’s HotSpot and Microsoft’s.Net environment  First introduced as part of the Smalltalk implementation

14 14 Steamloom  Java interpreter with built-in support for aspects  Based on IBM’s Jikes Research Virtual Machine (RVM) for Java  Aspects, PCDs and advices are first-class entities taken care of by the VM  Built-in support for C AESAR deployment approach  Deployment scope can be either global, thread-local or instance-local  Pointcuts may include function calls only

15 15 steam+loom a la google

16 16  Based on Just-in-time compilation  Three modes of operation  Baseline compiler  Optimizing compiler  Adaptive optimization system (AOS)  Classes and methods are kept as instances of VM_Class and VM_Method Jikes RVM in a nutshell TIB An object TIBstatus... m()... lazy compilation stub m()’s compiled code m()’s optimized code TIB An object TIBstatus... m()... lazy compilation stub m()’s compiled code m()’s optimized code

17 17 Adaptive Optimization System (AOS)  Methods are initially compiled by the regular compiler and optimized whenever the system sees fit  Has three modules:  Run-time measurements subsystem – gathers profiling data and stores it in the AOS database  Controller – decides on re-compilation of methods  Recompilation unit – called by the controller whenever recompilation of a method is required

18 18 Adding Weaving Support  Upon weaving of an aspect, modify and recompile relevant methods.  Concern:  Methods may be inlined.  Advice:  For each method m(), keep the set of methods in which m() was inlined  Upon recompilation of m(), recompile all affected methods

19 19 Input: m 0, method to be re-compiled Output: REC, the set of affected methods REC = {m 0 } M = REC; do M’ =  ; foreach m  M do M’  inline_locations(m); M = M’\ M; REC  M; until M =  Setting the order of recompilation

20 20 TIB An object TIBstatus... m()... lazy compilation stub m()’s compiled code m()’s optimized code with advice invocation code Class-Wide Aspect Weaving  Modify m() ’s bytecode  Change m() ’s entry in the TIB  m() was not optimized: to the lazy compilation stub  m() was optimized: Recompile m() and all affected methods m()’s compiled code with advice invocation code m()’s optimized code with advice invocation code m()’s compiled code with advice invocation code

21 21 Instance- Local Aspect Weaving  Clone original TIB and method  Treat m() as in the class-wide case  Methods of classes for which an instance local aspect exists cannot be inlined! TIB o1 TIBstatus... m()... o2 TIBstatus... m()’s original code m() with aspects TIB o1 TIBstatus... m()... o2 TIBstatus... TIB... m()... m()’s original code

22 22 Thread-Local Aspect Weaving  A brief snippet of code is inserted before every thread-local join point:  Check thread identity  Skip advice invocation in case the aspect need not to be active in current thread

23 23 Performance Evaluation  Steamloom has been compared against  AspectJ, executed on Sun’s HotSpot (AspectJ/HS)  AspectJ, executed on Jikes RVM (AspectJ/RVM)  Effect on code with no aspects:  AspectJ/HS is 2.5 times faster than Steamloom,  AspectJ/RVM is a little faster than Steamloom  Effect on code with static aspects:  similar to the no-aspects case  Effect on code with dynamic aspects:  Steamloom is 2-4 times faster than AspectJ/HS,  Steamloom is 17 times faster than AspectJ/RVM

24 24 Related Work  Pre-run-time instrumentation  EAOP, JAC, Jboss, AOP, PROSE 2  Run-time event monitoring  PROSE 1  Run-time weaving  Wool, AspectS  Continuous weaving

25 25 Conclusions and Future Work  Support on the VM level is required for efficient implementation of dynamic pointcuts  Recompilation at runtime is required for such support  Many features are still missing, in particular the around() advice  Implementation of Steamloom’s features on HotSpot

26 26 References  Virtual Machine Support for Dynamic Join points: http://www.st.informatik.tu- darmstadt.de/database/publications/data/Steamloom.pdf?i d=80  Steamloom’s homepage: http://www.st.informatik.tu- darmstadt.de/static/pages/projects/AORTA/Steamlo om.jsp  Just-in-time compilers: http://en.wikipedia.org/wiki/Just_In_Time_compilation.html  Jikes RVM webbpage http://www-124.ibm.com/developerworks/oss/jikesrvm/  History of steam looms http://www.fordham.edu/halsall/mod/1823cotton.html


Download ppt "Virtual Support for Dynamic Join Points C. Bockisch, M. Haupt, M. Mezini, K. Ostermann Presented by Itai Sharon"

Similar presentations


Ads by Google