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

1. Phx.MorphWhy 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 Phx.Morph Determine if Aspect-Oriented Programming (AOP) can improve Phoenix development Our approach • Use Phoenix to develop an AOP solution • Then turn around and use the AOP solution to help develop Phoenix

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. Weaving using Phx.Morph Post-Link Step Normal assemblies containing custom AOP attributes Aspect Assemblies Source Files Original Program WovenProgram Phx.Morph Compiler 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 Depends On Depends On Depends On OO design is tightly coupled and hard to maintain

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

12. Phoenix client extensibility:Traditional OO • 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

13. Phoenix client extensibility:Open Classes • Empowers clients • High performance • Type safe • Don’t have to wait for RDK drop • Don’t require help from Phoenix team • Weave Phx.dll • To add BirthPhase field directly to Instr 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 classLogReflectionAspect { [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 Injected code 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)

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 • Built using Phoenix • MorphPlugin plugs into PEREW and uses Phx.Morph to perform weaving Phx.Morph Editors Open Classes, weaving AOP Joinpoints, pointcuts, … PEREW Assembly Re-Writer Attributes Custom AOP attributes MorphPlugin Phoenix Core API

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. Related work “Real” (shipped) products IBM WebSphere HyperProbes AspectJ™ BEA JRockit JVM PROSE Axon JAsCo Nanning IBM Eclipse JBoss (J2EE) JMangler Products DynAOP EAOP Steamloom SiteVision Jakarta Hivemind CeaserJ JAML Spring (J2EE) Jiazzi Java JAC Arachne .NET Phx.Morph AspectC TinyC2 Rapier.NET Aspect# C++ AspectC++ No real products Loom.NET AspectDNG FeatureC++ Weave.NET Meta.NET Wool XWeaver Other JAsCo.NET Eos Aspect.NET Aspects AspectS PostSharp SetPoint CLAW AOPHP Compose* Apostle Poly Hyper/J SourceWeave.NET AspectCOOL PHPaspect DemeterJ AopDotNetAddin Pythius AOP.NET PEAK Encase Composition Filters AspectScheme AspectL AOP-Engine AspectCocoa Concern Manipulation Environment AspectR Italics = Microsoft-sponsored (although none are shipped)

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

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

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