1 / 26

Just-In-Time Aspects

Just-In-Time Aspects. Based on: Efficient Dynamic Weaving for Java By: Andrei Popivici, Gustavo Alonso and Thomas Gross Dynamic Aspect Oriented Infrastructure By: Andrei Popivici, Gustavo Alonso and Thomas Gross Presented by: Moshe Sapir.

evania
Download Presentation

Just-In-Time Aspects

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. Just-In-Time Aspects Based on: Efficient Dynamic Weaving for Java By: Andrei Popivici, Gustavo Alonso and Thomas Gross Dynamic Aspect Oriented Infrastructure By: Andrei Popivici, Gustavo Alonso and Thomas Gross Presented by: Moshe Sapir

  2. Just-In-Time Aspects: Agenda • What are dynamic aspects? • Why we need dynamic aspects? • Requirements of dynamic aspects system • Implementation Alternatives • Proposed implementation • Performance analysis

  3. What are dynamic aspects The ability to apply, replace or remove an aspect while the application is running. In systems like AspectJ, although the aspects may be defined using dynamic properties of the program, it is impossible to change the definition of the aspect or add new one on the fly. We would like to eliminate this limitation.

  4. Q: Why we need dynamic aspects?A: Application Awareness • The computing environment is aware of the applications running within its boundaries • The environment provides application the necessary adaptation to the local condition.

  5. Q: Why we need dynamic aspects?A: Application Awareness: Robotics • The robot is initially programmed with basic, non task specific instructions (the rules of Asimov ) • The tasks of the robot are logically broken to basic macros (aspects?!) • The macros are loaded/unloaded to the robot according its current task and environment without changing its basic software

  6. Q: Why we need dynamic aspects?A: Application Awareness: Mobile devices • Mobile systems have limited storage space. • The device can dynamically acquire functionality when it changes location. • Example: electronic catalog can be updated when host device enters commercial conference. The content of the catalog is dynamically woven aspect. • The new functionality might (and might not) have cross-cutting nature: encryption, network protocol.

  7. Q: Why we need dynamic aspects?A: Patching servers • The basic, unwoven code of the application will contain no major functionality. • The application’s logic will be implemented as an aspect which is woven to the basic code. • This enables elegant on the fly patching of the system. • Adds atomic weaving requirement to the dynamic AOP system.

  8. Q: Why we need dynamic aspects?A: On the fly debugging • The customer is provided with application without tracing or debugging capabilities. • Once a problem is encountered, and if the application has not entirely crashed (often the case with web applications), tracing is woven into the application without stopping it. • Once the problem is understood and fixed, the tracing is woven out and the fix is woven in.

  9. Requirements from dynamic AOP system • Minimal overhead on non-advised code Under normal operations (no woven aspects), the dynamic AOP system should not lead to significant performance hit. • Secure and atomic weaving Secure: The system should be able to control which local resources can be accessed by the advice code. Atomic: weaving operation must appear to the application as one atomic step. Non atomic weaving may lead to inconsistency. • Efficient advice execution Calling the advice code need to be done efficiently. • Flexibility The system need to be independent of the actual AOP paradigm (AspectJ, HyperJ …). I.E provide infrastructure instead of implementation of particular AOP dialect.

  10. Implementation alternatives:When is the weaving done? source files Compiler Weaver class files ? VM Loader Weaver Class byte code ? JIT compiler Weaver Native

  11. Implementation alternatives:Load time vs. JIT time weaving • Mainly for efficiency reasons, the JIT approach was chosen • This means re-implementing the AOP engine for each machine instruction set

  12. Implementation alternatives:Inline weaving Class C Aspect A [C.foo() bytecode] Before C.foo {print(”Moshe”);} JIT Weaver Save %sp, 112, %sp Sethi %hi(iob+32), %o0 Sethi %hi(.LLc0), %o1 or %o0, %lo(iob+32), %o0 call print, 0 or %o0, %lo(.LLc0), %o1 cmp %10, 0 bne .LL7 nop b .LL9 mov 1, %10 .LL7: call foo, 0 add %i0, %o0, %o0 … Woven Aspect foo body

  13. Implementation alternatives:Stub weaving Class C Aspect A [foo bytecode] Before C.foo {print(”Moshe”);} JIT Weaver call weaver, 0 mov %i0, %o0 cmp %10, 0 bne .LL7 nop b .LL9 mov 1, %10 .LL7: call foo, 0 add %i0, %o0, %o0 smul %i0, 1, %o0 .LL9: ret restore Woven Aspect foo body

  14. Implementation alternatives:Inline weaving vs. Stub weaving • For security reasons, the Stub Weaving approach was chosen • This will increase machine cycles per guarded method/field access even if the advice is empty

  15. Dynamic AOP system Implementation:JVM Support • Weaving in the JIT level implies that we must have JVM support. • However, we would like to minimize the functionality performed by the JVM. • Solution schema: when asked to apply new aspect the JVM will: • Prepare the system for new code insertion: some classes might be re JIT compiled and reloaded. • Insert a hook in the native code on every place an aspect might be invoked • The hook will contain a callback to aspect dispatcher that is not implemented in the JVM level.

  16. Dynamic AOP system ImplementationHigh level architecture

  17. Dynamic AOP system Implementation:Extra interface provided by the JVM Interface JoinPointManager { void aopScope(String[] guardedClasses); void watchMethodEntry(Method m, Object tag); void watchMethodExit (Method m, Object tag); void watchFieldAccess (Field f, Object tag); … } • Each JVM which supports dynamic aspects need to implement this interface. • aopScope method initializes the system with the name of the classes to guard. • The tag parameter of the watch* methods will be provided back to the AOP system when the join point is reached. In contains the advice byte code.

  18. Dynamic AOP system Implementation:Interface provided by the AOP engine Interface Weaver { void onMethodEntry(JoinPoint jp); void onMethodExit (JoinPoint jp); void onFieldAccess (JoinPoint jp); … } • The on* methods are called by the JVM each time matching join-point is reached. • The JoinPoint object contains the tag provided to the JVM when the aspect was loaded. • It also contains context specific data for dynamic checks, such as the state of the stack, variable values act. Building this object presents a major performance hit.

  19. Dynamic AOP system Implementation:Callback implementation schema void onMethodEntry(JoinPoint jp) { // Given the dynamic envoirnament such as variable values // and the state of the stack, decide whether // to execute the advice. if (!dynamicChecks(jp)) { return; } // Advice execution byte[] adviceCode = jp.aopTag; executeCode(adviceCode); } • Call to this method is woven by the JIT to the native code. • The JoinPoint object contains all the dynamic information needed to decide whether to execute the advice. • It also contains the advice code.

  20. Addressing requirements:Minimal overhead on unwoven code • By design, there should be no overhead on unwoven code, since the hooks are inserted to explicitly requested classes. • However, JVM that supports the JoinPointManager interface suffers small performance hit which is introduced by adding the new functionality.

  21. Addressing requirements:Secure and atomic weaving • The advice code is not directly woven to the native: major security advantage. • The advice code is not directly exposed to the main execution environment. It is passed to the advice as a callback parameter. This provides support to the existing security models in Java. • Atomic weaving can be achieved using the JVM support. This is not a trivial task since the JVM needs to make sure that all threads are stopped and not executing code of a newly woven class

  22. Addressing requirements: Flexibility • The proposed system does assume any AOP methodology and supports the requirements of all the exiting methodologies. • The concrete methodology will need to: • Identify the join-points defined by the user • Compile the advice code • Call the appropriate watch* methodon the JVM JoinPointManager interface • Implement the weaver interface (the callback methods)

  23. Performance analysis Overhead of the dynamic AOP enhancement of the JVM and JIT compiler. The measurements were taken without actually monitoring the classes or weaving aspects. The performance hit is mainly result of introducing new code to the JVM

  24. Performance analysis Relative increase of the application code size due to weaving of join-point stubs AOP programming encourages smaller methods. Application developed with AOP orientation will suffer more from introducing new code on each method call.

  25. Performance analysis Join point execution time comparison with the standard AspectJ system.

  26. Conclusions • Dynamic AOP empowers the system’s designer with new capabilities. • As always, enriching the expressive power of the designer costs in runtime performance hit. • However, if the designer would have been forced to implement those capabilities by himself, most probably he would have come up with less efficient implementation than the JIT weaver.

More Related