Demo 9: Phx.Morph Byte code weaving using Microsoft’s Phoenix compiler Marc Eaddy Columbia University

Demo 9: Phx.Morph

Byte code weaving using Microsoft’s Phoenix compiler

Marc Eaddy

Columbia University

Copyright (C) Marc Eaddy AOSD 2006 Demo 2

Outline• Phx.Morph overview

• Phoenix background

• Phx.Morph implementation

• Demos: Open Classes and AOP

• Statement annotations

• Microsoft and AOP


Why our work is interesting• Built using Phoenix – Microsoft’s

production-grade compiler, analysis and tools infrastructure– Capable of weaving very large programs– Produces debug information

And soon...• Distributed with Phoenix SDK• Statement-level advising using statement

annotations• Dynamic weaving using Microsoft’s new

Debugger APIs and our Wicca system– Byte code weaving– Breakpoint weaving– Source weaving


Background• The Phoenix Project

– Microsoft’s production-grade compiler, analysis,and tools infrastructure

– Will become backend for all Microsoft compilers

– Massive software project– Currently 1.8M LOC (318K hand-written)


Problem• Many Phoenix requirements cannot be

cleanly separated using traditional OO techniques (inheritance and aggregation)– Multiple clients and scenarios

• Orthogonal requirements• Unanticipated requirements

– “Operational” (nonfunctional) requirements

• Traditional OO solutions result in increased software complexity– Designs are complex and highly coupled– Code is cluttered and difficult to write and

maintain

• Many other groups at Microsoft are also struggling with this problem


Our initial goalDetermine if Aspect-Oriented

Programming (AOP) can improve Phoenix development

Our approach1.Use Phoenix to develop an AOP solution

2.Then turn around and use the AOP solution to help develop Phoenix

Phx.Morph


Compiler Phx.Morph WovenProgram

AspectAssemblies

Weaving using Phx.Morph

OriginalProgram

SourceFiles

BreakpointsDeltas

Static Weaving

Dynamic Weaving


Phx.Morph architecture

Phx.Morph

EditorsOpen Classes, binary and breakpoint weaving

Phoenix-specific AOP

Attribute Handlers

Phoenix

PEREWAssemblyRe-Writer

Phx.Aop

AOPJoinpoints, pointcuts, …

AttributesCustom AOP annotations

.NET

MorphPlugin


Open ClassesAbility to split a class definition into separate modules• aka “intertype declarations”

• Similar to partial classes in C# except– extends classes after they’ve been

compiled– works on assemblies

• no source req’d• language agnostic

• We support adding fields, properties, methods, base interfaces and classes


Original class

+AddChild(in child : Node)+GetChild(in id : int) : Node+GetChildCount() : int

-children

Node

BooleanExpressionNode

-condition : BooleanExpressionNode-body : Node

WhileLoopNode

-condition : BooleanExpressionNode-thenBody : Node-elseBody : Node

IfThenNode


+AddChild(in child : Node)+GetChild(in id : int) : Node+GetChildCount() : int+Accept(in visitor : INodeVisitor)

-children

Node

+Accept(in visitor : INodeVisitor)




WhileLoopNode



IfThenNode

+visit(in node : Node)+visit(in node : BooleanExpressionNode)+visit(in node : WhileLoopNode)+visit(in node : IfThenNode)

INodeVisitor

Adding the Visitor pattern:Traditional OOD

Depends On

Depends On

Depends On

Depends On

OO design is tightly coupled and hard to

maintain

OO design is tightly coupled and hard to

maintain


Adding the Visitor pattern:Open Classes

+visit(in node : Node)+visit(in node : BooleanExpressionNode)+visit(in node : WhileLoopNode)+visit(in node : IfThenNode)

INodeVisitor


[Extends("Node")]


[Extends("BooleanExpressionNode")]


[Extends("WhileLoopNode")]


[Extends("IfThenNode")]

DependsOn

+AddChild(in child : Node)+GetChild(in id : int) : Node+GetChildCount() : int

-children

Node



WhileLoopNode


IfThenNode

Open Classes design breaks the circular dependency and

centralizes the code

Open Classes design breaks the circular dependency and

centralizes the code


AOPAbility to inject code at specific points in a program

– profiling– logging and tracing– log field get/set– dirty bit (persistence, synchronization)– change notification (undo/redo/rollback)– enforce invariants (non-null, const, data flow,

Design by Contract)– error checking/handling– fault injection– caching/memoization– proxies/delegation– asynchronous methods– design patterns (visitor, adaptor, factory, …)– Quality of Service– etc. etc.


Demo: Logging reflection usage

• Want to log a message whenever we use the Reflection API

• Self-weave Phx.Morph.dll


Reflection logging aspectusing Phx.Aop;using Phx.Aop.Attributes;

public class LogReflectionAspect{ [Advice(AdviceType.before, "call(* System.Reflection.*.*(..))")] static public void LogReflection([Signature] string signature,

[WithinSignature] string withinSignature, [FileName] string fileName, [Line] uint line) { System.Console.WriteLine("Called " + signature); System.Console.WriteLine(" inside " + withinSignature); System.Console.WriteLine(" [File: {0}, Line: {1}]", fileName,

line); }}


Statement annotations for AOPpublic void transferFundsTo(float amount,

BankAccount destination){[Trace] AuthorizationRequest ar = new

AuthorizationRequest(this, destination);...[Trace] destination.deposit(amount);...[Log("Obtaining authorization. This could take awhile...")]bool result = ar.authorizeTransferOfFunds(amount);...


Using statement annotations in pointcuts[Advice(AdviceType.afterReturning, "call([Trace] *.new(..)")

static void InstanceTrace([This] object o) {instances.add(o);

}

[Advice(AdviceType.before, "call([Trace] * *(..))")static void StatementTrace([Signature] string sig) {System.Console.WriteLine("Calling " + sig);

}

[Advice(AdviceType.before, "annotation([Log])")static void LogAdvice(

[Attribute1] LogAttribute logAttr) {System.Console.WriteLine(logAttr.value);

}


Current limitations• Imported methods cannot access private

members• Cannot weave signed code• Limited aspect instantiation model

– Instance advice methods are imported– Static advice methods are referenced

• Not yet implemented– Can’t import methods with multiple return

statements– Around advice– Many pointcuts not implemented (including

cflow)– Only execution pointcuts can access the args

and target context

Microsoft and AOP


AspectJ™

PROSE

Hyper/J

JAsCo

EAOP

JMangler

AspectC++

CeaserJ

AspectC

Steamloom

AspectS

FeatureC++

DynAOP

Apostle

AspectR

Spring (J2EE)

DemeterJ

Concern Manipulation Environment

Eclipse

IBM WebSphere

HyperProbes

JBoss (J2EE)

BEA JRockit

JVM

AspectScheme

Aspects

AOPHP

Composition Filters

Jakarta Hivemind

JAML

XWeaver

PEAKPythiusPHPaspect

AspectL

AspectCocoa

Loom.NET

Weave.NET Meta.NET

Rapier.NETAspect#

Aspect.NET

AspectDNG

SetPoint CLAWPostSharp

Eos

Compose*

EncaseAOP-Engine

SourceWeave.NETAopDotNetAddin

Phx.Morph

Other

Java

C++

.NET

Products

AOP technologies

Italics = Microsoft-sponsored (although none are shipped)

AOP.NET

Wool

AspectCOOL

JAC

Nanning

JAsCo.NET

No “real” products

SiteVision

Axon

Arachne

Jiazzi

Poly

TinyC2 Wicca


Why is Microsoft waiting?• Comprehensibility

– Must be able to predict behavior– Must be easy to understand (Einstein, Elvis, Mort)– Integration into existing tools and software processes– Aspects in-the-large (reuse, composition, mining)

• Debuggability– Source-level debugging is critical– Both obliviousness and intimate AOP debugging– Debugging injected code

• Testability– AOP introduces new fault models

• Serviceability– EXE/DLL boundary no longer signifies ownership– How to isolate faults and assign blame?– Version currently linked to size/date– How to patch woven programs?


AOP support in .NET• Static weaving

– Limited byte code instrumentation tools– CodeDOM API not fully implemented

• Parsing not implemented• Can’t access/weave byte code• AST can’t represent all of C#

• Dynamic weaving– Discouraged in general– Can’t specify custom class loader– Edit-and-Continue API

• Debug only• Inefficient• Hard to specify patches


Conclusion• Our goal was to determine if AOP

would improve Phoenix development– Re-implemented a Phoenix plug-in to

use Open Classes– Grafted adapter interfaces onto Phoenix

classes– Validated the feasibility of using

Phx.Morph on Phoenix itself

• Learned why Microsoft is timid about using AOP


Future work• Address barriers to adoption

– Comprehensibility, Debuggability, Testability, Serviceability

• Lobby for more AOP support in .NET

• Statement annotations

• Dynamic weaving


ContactMarc Eaddy

[email protected]

Try it out!www.columbia.edu/~me133

(includes source)

Questions?

Extra slides


• Client wants to attach custom data to an object• Example: IR-Longevity plug-in tracks compiler

phase when an instruction is created

+Find()

-list

ExtensibleObject

+Attach()+Detach()+Register()

-id

ExtensionObject

+AddExtensionObject()+FindExtensionObject()

-...

Instr

+Register()+Get()

-id : int-BirthPhase : Phase

BirthPhaseExtensionObject

0..*Client’s

extensionobject

Client’sextension

object

Phoenix client extensibility:Traditional OOD


• Empowers clients– High performance– Type safe– Don’t have to wait for RDK drop– Don’t require help from Phoenix team

Phoenix client extensibility:Open Classes

• Weave Phx.dll• To add BirthPhase field directly to Instr

-BirthPhase : Phase

Instr Client’sextension

object

Client’sextension

object


Before weaving IL_0065: ldarg.0

IL_0066: call class System.Reflection.Assembly System.Reflection.Assembly::Load(string)


Woven result IL_0065: ldarg.0 IL_0066: ldstr "System.Reflection.Assembly.Load" IL_006b: ldstr "Phx.Morph.ReflectionHelpers.LoadAssembly" IL_0070: ldstr “c:\\phx\\rdk\\samples\\Morpher\\Phx.Morph\\

ReflectionHelpers.cs" IL_0075: ldc.i4 0xfb IL_007a: call void LogReflectionExt::LogReflection(

string,

string,

string,

uint32) IL_007f: call class System.Reflection.Assembly

System.Reflection.Assembly::Load(string)

Injected code

Documents

Demo 9: Phx.Morph Byte code weaving using Microsoft’s Phoenix compiler Marc Eaddy Columbia University