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)
BooleanExpressionNode
+Accept(in visitor : INodeVisitor)
-condition : BooleanExpressionNode-body : Node
WhileLoopNode
+Accept(in visitor : INodeVisitor)
-condition : BooleanExpressionNode-thenBody : Node-elseBody : Node
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
+Accept(in visitor : INodeVisitor)
[Extends("Node")]
+Accept(in visitor : INodeVisitor)
[Extends("BooleanExpressionNode")]
+Accept(in visitor : INodeVisitor)
[Extends("WhileLoopNode")]
+Accept(in visitor : INodeVisitor)
[Extends("IfThenNode")]
DependsOn
+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
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
Top Related