1 / 30

Demo 9: Phx.Morph Byte code weaving using Microsoft’s Phoenix compiler

Demo 9: Phx.Morph Byte code weaving using Microsoft’s Phoenix compiler. Marc Eaddy Columbia University. Outline. Phx.Morph overview Phoenix background Phx.Morph implementation Demos: Open Classes and AOP Statement annotations Microsoft and AOP. Why our work is interesting.

wyoming-meyer
Download Presentation

Demo 9: Phx.Morph Byte code weaving using Microsoft’s Phoenix compiler

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Outline • Phx.Morph overview • Phoenix background • Phx.Morph implementation • Demos: Open Classes and AOP • Statement annotations • Microsoft and AOP AOSD 2006 Demo

  3. 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 AOSD 2006 Demo

  4. 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) AOSD 2006 Demo

  5. 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 AOSD 2006 Demo

  6. Our initial 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 AOSD 2006 Demo

  7. Weaving using Phx.Morph Aspect Assemblies Source Files Original Program WovenProgram Phx.Morph Compiler Static Weaving Breakpoints Deltas Dynamic Weaving AOSD 2006 Demo

  8. Phx.Morph architecture Phx.Morph Morph Plugin PEREW Assembly Re-Writer Editors Open Classes, binary and breakpoint weaving Phoenix-specific AOP Attribute Handlers Phx.Aop Phoenix AOP Joinpoints, pointcuts, … Attributes Custom AOP annotations .NET AOSD 2006 Demo

  9. Open Classes Ability 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 AOSD 2006 Demo

  10. Original class AOSD 2006 Demo

  11. Adding the Visitor pattern:Traditional OOD Depends On Depends On Depends On Depends On OO design is tightly coupled and hard to maintain AOSD 2006 Demo

  12. Adding the Visitor pattern:Open Classes Open Classes design breaks the circular dependency and centralizes the code Depends On AOSD 2006 Demo

  13. AOP Ability 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. AOSD 2006 Demo

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

  15. Reflection logging aspect using 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); } } AOSD 2006 Demo

  16. Statement annotations for AOP public 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); ... AOSD 2006 Demo

  17. 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); } AOSD 2006 Demo

  18. 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 AOSD 2006 Demo

  19. Microsoft and AOP

  20. AOP technologies IBM WebSphere HyperProbes AspectJ™ BEA JRockit JVM PROSE Axon JAsCo Nanning JBoss (J2EE) JMangler Eclipse Products DynAOP EAOP Steamloom SiteVision Jakarta Hivemind CeaserJ JAML Spring (J2EE) Jiazzi Java JAC Arachne .NET Phx.Morph AspectC TinyC2 Wicca Rapier.NET C++ Aspect# 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) AOSD 2006 Demo

  21. 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? AOSD 2006 Demo

  22. 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 AOSD 2006 Demo

  23. 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 AOSD 2006 Demo

  24. Future work • Address barriers to adoption • Comprehensibility, Debuggability, Testability, Serviceability • Lobby for more AOP support in .NET • Statement annotations • Dynamic weaving AOSD 2006 Demo

  25. Try it out! www.columbia.edu/~me133 (includes source) Contact Marc Eaddy eaddy@cs.columbia.edu Questions? AOSD 2006 Demo

  26. Extra slides

  27. Phoenix client extensibility:Traditional OOD • 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 AOSD 2006 Demo

  28. 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 AOSD 2006 Demo

  29. Before weaving IL_0065: ldarg.0 IL_0066: call class System.Reflection.Assembly System.Reflection.Assembly::Load(string) AOSD 2006 Demo

  30. Woven 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) AOSD 2006 Demo

More Related