Just-In-Time Aspects

Based on:Efficient Dynamic Weaving for Java

By: Andrei Popivici, Gustavo Alonso and Thomas GrossDynamic 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 codeUnder normal operations (no woven aspects), the dynamic AOP system should not lead to significant performance hit.

2. Secure and atomic weavingSecure: 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 executionCalling the advice code need to be done efficiently.

4. FlexibilityThe 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

Weaver

Weaver

?

?

Implementation alternatives:Load time vs. JIT time weaving

Load time weaving JIT-Time Weaving

Portable Less portable

Less efficient Efficient

May require class reload May 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, %spSethi %hi(iob+32), %o0Sethi %hi(.LLc0), %o1or %o0, %lo(iob+32), %o0call print, 0or %o0, %lo(.LLc0), %o1cmp %10, 0bne .LL7nopb .LL9mov 1, %10

.LL7: call foo, 0add %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, 0mov %i0, %o0cmp %10, 0bne .LL7nopb .LL9mov 1, %10

.LL7: call foo, 0add %i0, %o0, %o0smul %i0, 1, %o0

.LL9: retrestore

[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 weaving Stub weaving

Reduced machine code size Large machine code size

Mix advice and base code Advice 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 ImplementationHigh level architecture

Java Virtual Machine

Join Point Manager

Callback Manager

Join Point Generator

[2.1] Search matches

[2.2] Static checks

[2.3] Create advice

[2.4] Create join-points

Weaver

[5.2] Execute Advice

[5.1] Dynamic checks

[1] ApplyAspect(Aspect)

[3] WatchMethodEntry (Join point) [4] OnMethodEntry (JoinPoint)

Dynamic AOP Engine

Execution monitor

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.

Benchmark Relative overhead

LUFact:Kernel 103.15%

Crypt:Kernel 103.24%

SOR:Kernel 98.74% (?!)

Sparse:Kernel 100.23%

Check 103.04%

Jess 110.19%

db 105.17%

Jack 107.84

Javac 113.51

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-point New code size

Method entry 126.3%

Method exit 124.9%

Field modification 111.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 type Dynamic AOP is disabled

Call to empty dynamic AOP advice

Call to empty AspectJ advice

Get field 12.9 ns 541.3 ns 108.3 ns

Put field 12.3 ns 548.0 ns 119.7 ns

Invoke virtual method

39.0 ns 513.9 ns 201.3 ns

Invoke interface method

662.6 ns 1121 ns 850.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.