1 / 26

Virtual Support for Dynamic Join Points

Virtual Support for Dynamic Join Points. C. Bockisch, M. Haupt, M. Mezini, K. Ostermann. Presented by Itai Sharon (itaish@cs.technion.ac.il ). Agenda. Classification of crosscuts Handling dynamic crosscuts Steamloom and support for aspects on VM level Evaluation Related work. Terms.

miach
Download Presentation

Virtual Support for Dynamic Join Points

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

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. Agenda • Classification of crosscuts • Handling dynamic crosscuts • Steamloom and support for aspects on VM level • Evaluation • Related work

  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. 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. 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. Quiz • Whenever foo() is called from bar() • Whenever foo() is called from cflow(bar()) • Whenever x is calledwhere x is a method obtained from the user Code-level crosscut Statically bound dynamic crosscut Unbound dynamic crosscut

  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. 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 CAESAR: deploy(anAspectInstance) {aBlock} deploy public class AnAspect { ...

  9. m1 Fibstart fib m2 The Fibonacci class classTestApp { public voidm1(intn) {fibstart(n);} public voidm2(intn) {fibstart(n);} public voidfibstart(intn) {fib(n);} public intfib(intk) { return (k>1) ? fib(k-1)+fib(k-2) : k; } }

  10. m1 Fibstart fib m2 Counting Calls to fib() via m2() (a la AspectJ) publicaspect FibonacciAspect { private intctr = -1; pointcut m2cf() : cflow(call(voidTestApp.m2(int))); before() : execution(voidTestApp.fibstart(int)) && m2cf() { ctr = 0;} after() : execution(voidTestApp.fibstart(int)) && m2cf() {System.out.println(ctr);} before () : execution(voidTestApp.fib (int)) && m2cf() { ctr++;} }

  11. m1 Fibstart fib m2 Counting Calls to fib() via m2() (a la CAESAR) publicclass FibonacciAspect { private intctr = -1; before() : execution(voidTestApp.fibstart(int)) { ctr = 0;} after() : execution(voidTestApp.fibstart(int)) {System.out.println(ctr);} before () : execution(voidTestApp.fib(int)) && m2cf() { ctr++;} } deploy public class DeploymentAspect { around() : call(voidTestApp.m2(int)) { deploy new (FibonacciAspect()) {proceed();} } }

  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. 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. 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 CAESAR deployment approach • Deployment scope can be either global, thread-local or instance-local • Pointcuts may include function calls only

  15. steam+loom a la google

  16. An object TIB TIB status status ... ... TIB lazy compilation stub An object ... ... m() m() m()’s compiled code ... ... TIB lazy compilation stub m()’s optimized code m()’s compiled code m()’s optimized code Jikes RVM in a nutshell • 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

  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. 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. Setting the order of recompilation Input: m0, method to be re-compiled Output: REC, the set of affected methods REC = {m0} M = REC; do M’ = ; foreach mM do M’ inline_locations(m); M = M’\ M; REC  M; until M = 

  20. TIB status ... An object ... m()’s compiled code with advice invocation code TIB m()’s compiled code m() m()’s compiled code ... lazy compilation stub lazy compilation stub m()’s compiled code with advice invocation code m()’s optimized code with advice invocation 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

  21. 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 TIB TIB TIB status status status status ... ... ... ... TIB TIB o1 o2 o2 o1 m()’s original code m()’s original code ... ... ... m() m() m() ... ... ... TIB m() with aspects Instance-Local Aspect Weaving

  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. 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. 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. 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. References • Virtual Machine Support for Dynamic Join points: http://www.st.informatik.tu-darmstadt.de/database/publications/data/Steamloom.pdf?id=80 • Steamloom’s homepage: http://www.st.informatik.tu-darmstadt.de/static/pages/projects/AORTA/Steamloom.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

More Related