1. Phx.Morph Why hasn’t Microsoft adopted Aspect-Oriented Programming? Marc Eaddy Columbia University

2. 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)

3. 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

4. Our goal Determine if Aspect-Oriented Programming (AOP) can improve Phoenix development Our approach 1.Use Phoenix to develop an AOP solution 2.Then turn around and use the AOP solution to help develop Phoenix Phx.Morph

5. 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

6. 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

7. Compiler Phx.Morph Woven Program Aspect Assemblies Post-Link Step Normal assemblies containing custom AOP attributes Weaving using Phx.Morph Original Program Source Files Original developer can be oblivious

8. 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

9. Original class

10. Adding the Visitor pattern: Traditional OO Depends On OO design is tightly coupled and hard to maintain

11. Adding the Visitor pattern: Open Classes Depends On Open Classes design breaks the circular dependency and centralizes the code

12. Client wants to attach custom data to an object Example: IR-Longevity plug-in tracks compiler phase when an instruction is created Client’s extension object Client’s extension object Phoenix client extensibility: Traditional OO

13. 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 Client’s extension object Client’s extension object

14. Advice Ability 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.

15. Demo: Logging reflection usage Want to log a message whenever we use the Reflection API Self-weave Phx.Morph.dll

16. Logging advice using 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); }

17. Weaved result IL_0065: ldarg.0 IL_0066: call class System.Reflection.Assembly System.Reflection.Assembly::Load(string)

18. 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\\Refle ctionHelpers.cs" IL_0075: ldc.i4 0xfb IL_007a: call void LogReflectionExt::LogReflection(string, string, uint32) IL_007f: call class System.Reflection.Assembly System.Reflection.Assembly::Load(string) Injected code

19. Logging output Called 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…

20. Phx.Morph implementation Phx.Morph Editors Open Classes, weaving AOP Joinpoints, pointcuts, … Attributes Custom AOP attributes Phoenix Core API PEREW Assembly Re-Writer MorphPlugin Built using Phoenix MorphPlugin plugs into PEREW and uses Phx.Morph to perform weaving

21. 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)

22. 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 PEAK Pythius PHPaspect AspectL AspectCocoa Loom.NET Weave.NET Meta.NET Rapier.NET Aspect# Aspect.NET AspectDNG SetPoint CLAW PostSharp Eos Compose* Encase AOP-Engine SourceWeave.NET AopDotN etAddin 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 TinyC 2

23. 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

24. 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

25. 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

26. Future work Address barriers to entry –Debuggability, Testing, Comprehension, Serviceability, Performance Lobby for AOP support in.NET Infect Microsoft with AOP

27. Acks Many thanks to the Phoenix team! Mentor: Weiping Hu Andy Ayers Julian Burger Jan Gray John Lefor Paddy McDonald Chuck Mitchell

28. Contact Marc Eaddy – eaddy@cs.columbia.edu

29. Extra slides

30. Demo: Adding foreach sugar using System.Collections; using Phx.Morph.Attributes; [Extends("Node")] class NodeEnumeratorAspect : Node, IEnumerable { [Add] public IEnumerator GetEnumerator() { return new NodeEnumerator(this); } Class to extend “Add this method” “Add this iface”

31. NodeEnumerator public class NodeEnumerator : IEnumerator { Node node; int index = -1; public NodeEnumerator(Node node) { this.node = node; } public object Current { get { return node.GetChild(index); } } public bool MoveNext() { return ++index < node.ChildCount; } public void Reset() { index = -1; } }

32. foreach client static void DumpNode(Node root, string indent) { if (root == null) return; System.Console.WriteLine(indent + root); foreach (Node child in root) { DumpNode(child, indent + " "); } New capability!

33. Demo: Enforcing invariants Supporting const-ness at runtime Person teacher = new Person(); teacher.Salary = 25000; teacher.IsConst = true; teacher.Salary = 1000000; Caveat: Must weave all clients New! Invariant violated!

34. Invariant aspect [Extends("Person")] class InvariantAspect { [Add] public bool IsConst; [Advice(AdviceType.before, "set(Person.*)")] void CheckIsConst( [SourceLocation.WithinSignature] string withinSignature, [This] object This) { if (IsConst) { System.Console.WriteLine( "Person '{0}' violated IsConst constraint inside {1}", This, withinSignature); }

35. 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

36. CLR wish list New partial metadata keyword –Extends the C# Partial Classes concept beyond compile time and makes it language neutral –Compiler support: Class definition = class source files + partial class source files + partial classes defined in referenced assemblies –Runtime support: Combines partial classes at load-time Complete CodeDOM API –Express all C# and C++/CLI language constructs –Express complete syntax tree (including comments and whitespace) –Parsers for C# and C++/CLI Weaving at runtime –Ability to add fields, methods, etc. after load-time (ModuleLoadFinished) –Fix ICorProfiler.SetFunctionReJIT (don’t want to use out-of- process debugger API solution) –Support for JIT deoptimization Metadata embedded in IL –Ability to explicitly specify joinpoints (expands joinpoint model) –Ability to pass extra information to the aspect (specific message to log)

37. 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

38. More future work Next step is a proof-of-concept –Determine small piece of Phoenix to aspectualize –Design aspect solution –Implement remaining required AOP functionality –Modify Phoenix build process to perform post-link weaving step 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

39. 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