Phx.Morph Why hasn’t Microsoft adopted Aspect-Oriented Programming?

Phx.Morph

Why hasn’t Microsoft adopted Aspect-Oriented Programming?

Marc Eaddy

Columbia University

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)– Unanticipated requirements– Requirements to satisfy multiple clients and

scenarios– “Operational” (non-functional) requirements

• Traditional OO solutions resulted 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 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

Aspect-Oriented Programming

• Promise of greater “separation of concerns”

• AOP = Open Classes + Advice– Open Classes (type changes)– Advice (code/behavior changes)

• AspectJ™ is the canonical AOP specification and implementation

AOP buzzwords• joinpoint – an execution event

– function call, function execution, field access, exception, etc.

• advice – code that the programmer wants to be called before, after, or instead of (around), some joinpoint

• pointcut – a pattern for matching joinpoints– e.g., “System.Output.*”

• weaving – transforming a program to call advice code

Compiler Phx.Morph WovenProgram

AspectAssemblies

Post-Link StepNormal assemblies containing custom

AOP attributes

Normal assemblies containing custom

AOP attributes

Weaving using Phx.Morph

OriginalProgram

SourceFiles

Original developer can be oblivious

Original developer can be oblivious

Open Classes (OC)Ability to split a class definition into separate modules• Similar to Partial Classes in C#

except– post-link time; can extend a class at any

time– works on assemblies; no source req’d– language agnostic

• We support adding fields, properties, methods, base interfaces, and base 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 OO

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

• 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 OO

• 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

AdviceAbility to inject code at specific points in a program

– profiling– logging/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

Logging adviceusing Phx.Morph.Aop;using Phx.Morph.Attributes;

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

[SourceLocation.WithinSignature] string withinSignature, [SourceLocation.FilePath] string filePath, [SourceLocation.Line] uint line) { System.Console.WriteLine(); System.Console.WriteLine("Called {0}()", signature); System.Console.WriteLine(" inside {0}()", withinSignature); System.Console.WriteLine(" [File: {0}, Line: {1}]", System.IO.Path.GetFileName(filePath), line); }}

Weaved result IL_0065: ldarg.0

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

Weaved 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

Logging outputCalled System.Reflection.Assembly.Load() inside Phx.Morph.ReflectionHelpers.LoadAssembly() [File: ReflectionHelpers.cs, Line: 251]

Called System.Reflection.Emit.AssemblyBuilder.DefineDynamicModule()

inside Phx.Morph.Attributes.AttributeHelper.CreateTypeBuilder() [File: AttributeHelper.cs, Line: 499]

Called System.Reflection.Emit.ModuleBuilder.DefineType() inside Phx.Morph.Attributes.AttributeHelper.CreateTypeBuilder() [File: AttributeHelper.cs, Line: 504]

…etc…

Phx.Morph implementation

Phx.Morph

EditorsOpen Classes, weaving

AOPJoinpoints, pointcuts, …

AttributesCustom AOP attributes

Phoenix Core API

PEREWAssemblyRe-Writer

MorphPlugin

• Built using Phoenix• MorphPlugin plugs

into PEREW and uses Phx.Morph to perform weaving

Current limitations• Managed-code only• Cannot access private members• Problems weaving inlined code• Cannot weave signed code• Limited aspect instantiation model

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

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

statements– Around advice– Many pointcuts not implemented (including

cflow)– Aspect composition and precedence– Access to some joinpoint context (Args,

Target, thisJoinPoint)

AspectJ™PROSE

Hyper/J

JAsCo

EAOP

JMangler

AspectC++

CeaserJ

AspectC

Steamloom

AspectS

FeatureC++

DynAOP

Apostle

AspectR

Spring (J2EE)

DemeterJ

Concern Manipulation Environment

IBM 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

Related work

Italics = Microsoft-sponsored (although none are shipped)

AOP.NET

Wool

“Real” (shipped) products

AspectCOOL

JAC

Nanning

JAsCo.NET

No real products

SiteVision

Axon

Arachne

Jiazzi

Poly

TinyC2

AOP support in .NET• Static weaving

– CodeDOM• Parsing not implemented• AST can’t represent C++/CLI or all of C#

– Limited byte code instrumentation tools– Debug information gets out of sync

• Dynamic weaving– Discouraged in general– Can’t specify custom class loader– Profiler API

• Limited interception capabilities• Not able to force a method to be re-JIT’d• No support for Open Classes

– Edit-and-Continue API• Debug only• Inefficient• Hard to specify patches

Why is Microsoft waiting?• Comprehension

– Must be able to predict behavior– Must be easy to understand– Integration into existing tools and software processes– Aspects in-the-large

• Debuggability– Source-level debugging is critical– Phx.Morph keeps debug information in sync– Wicca allows full source-level debugging

• Testing– AOP introduces new fault models

• Serviceability– EXE/DLL boundary no longer signifies ownership– Version currently linked to size/date– Origin tracking needed to isolate faults (repudiation)

• Evolution• Performance

Conclusion• Our goal was to determine if AOP

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

use Open Classes– Began prototyping grafting 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 entry

– Debuggability, Testing, Comprehension, Serviceability, Performance

• Lobby for AOP support in .NET

• Infect Microsoft with AOP

Acks• Many thanks to the Phoenix team!

• Mentor: Weiping Hu

• Andy Ayers

• Julian Burger

• Jan Gray

• John Lefor

• Paddy McDonald

• Chuck Mitchell

ContactMarc Eaddy – [email protected]

Extra slides

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

production-grade compiler, analysis and tools infrastructure– Capable of weaving very large programs (e.g.,

Phoenix itself, which is 1.8M LOC)– Evolves in parallel with Phoenix and the

Common Language Runtime (performance improvements, bug fixes, API evolution, etc.)

• Used by Phoenix to solve real business requirements– Phoenix is real software– Hampered by traditional OO techniques– We’ve started using AOP to develop Phoenix

Future work• Work on Microsoft’s key blocking issues

– Debuggability– Maintainability– Performance– Versioning– Serviceability

• Explore more AOP scenarios– compile-time (ala Partial Classes for C++)

• Makes it easier for Phoenix to use their own extensions• Easily separate hand-written code from generated code

(code behind)

– load-time• Needed to fully support compile-time weaving

– runtime (dynamic weaving)• Useful for on-the-fly debugging and rapid prototyping

• Improve ease-of-use– IDE integration, projecting aspects into source code

Conclusions• Our goal was to determine if AOP

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

use Open Classes instead of the OO extension API

– Began prototyping grafting adapter interfaces onto Phoenix classes to integrate with another library

– We validated the feasibility of using Phx.Morph on Phoenix itself

Documents

Phx.Morph Why hasn’t Microsoft adopted Aspect-Oriented Programming?