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

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

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.

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.

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

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.

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.

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.

Requirements from dynamic AOP system 1. Minimal overhead on non-advised code Under normal operations (no woven aspects), the dynamic AOP system should not lead to significant performance hit. 2. 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. 3. Efficient advice execution Calling the advice code need to be done efficiently. 4. 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.

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

Implementation alternatives: Load time vs. JIT time weaving Load time weavingJIT-Time Weaving PortableLess portable Less efficientEfficient May require class reloadMay require re-JIT-Compile  Mainly for efficiency reasons, the JIT approach was chosen  This means re-implementing the AOP engine for each machine instruction set

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

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

Implementation alternatives: Inline weaving vs. Stub weaving Inline weavingStub weaving Reduced machine code sizeLarge machine code size Mix advice and base codeAdvice and base code are separate  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

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.

Dynamic AOP system Implementation High level architecture

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.

Dynamic AOP system Implementation: Interface provided by the AOP engine  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. Interface Weaver { void onMethodEntry(JoinPoint jp); void onMethodExit (JoinPoint jp); void onFieldAccess (JoinPoint jp); … }

Dynamic AOP system Implementation: Callback implementation schema  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. 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); }

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.

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

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* method on the JVM JoinPointManager interface Implement the weaver interface (the callback methods)

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. BenchmarkRelative overhead LUFact:Kernel103.15% Crypt:Kernel103.24% SOR:Kernel98.74% (?!) Sparse:Kernel100.23% Check103.04% Jess110.19% db105.17% Jack Javac The performance hit is mainly result of introducing new code to the JVM

Performance analysis Relative increase of the application code size due to weaving of join-point stubs Type of join-pointNew code size Method entry126.3% Method exit124.9% Field modification111.8% AOP programming encourages smaller methods. Application developed with AOP orientation will suffer more from introducing new code on each method call.

Performance analysis Join point execution time comparison with the standard AspectJ system. Instruction typeDynamic AOP is disabled Call to empty dynamic AOP advice Call to empty AspectJ advice Get field12.9 ns541.3 ns108.3 ns Put field12.3 ns548.0 ns119.7 ns Invoke virtual method 39.0 ns513.9 ns201.3 ns Invoke interface method ns1121 ns850.1 ns

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.