• Projects:

  • Debugging Aspect-Enabled Programs: Extract and Whitepaper

  • Wicca: Extract, Presentation and Diagrams

  • Phx.Morph: Extract, Whitepaper and Presentation

  ---

PHX.MORPH
Marc Eaddy (eaddy@cs.columbia.edu)
http://www.columbia.edu/~me133
Columbia University

ABSTRACT

We present Phx.Morph, a static byte-code weaver that enables Open Classes and Aspect-Oriented Programming for .NET. Phx.Morph is built on top of Phoenix, Microsoft’s industrial-strength back-end compiler framework. Phx.Morph is powerful enough to weave Phoenix itself (1.3 MLOCs), has the unique capability to generate debug information (PDBs), and is semi-officially supported by Microsoft.

Background and Motivation

This project started as a research project to explore using open classes as a way for researchers to extend Phoenix compiler classes with their own custom data. For example, a researcher would like to attach their custom analysis data to Instr or Opnd objects created by Phoenix during compilation. Currently, the researcher would need to add their custom data as an extension object that is stored in a list in the Instr or Opnd object. The disadvantages of this approach are: 1) the Instr and Opnd classes require additional code for maintaining and accessing the list, 2) only classes that support this extension list can be extended, and 3) it is inefficient due to the overhead involved in accessing extension objects in the list. In searching for a solution to the problem we decided that open classes was the best approach. In addition to separating concerns nicely the solution is very efficient as field accesses are resolved statically at compile-time. We decided to generalize the approach so that open classes would be available for extending any .NET assembly, not just Phoenix. At some point, we decided to integrate the peweave Phoenix RDK sample into Phx.Morph to support general-purpose AOP.

Goals

Our morphing solution should be transparent, efficient, and seamless. Transparency is achieved by allowing the original developer to be oblivious. They do not need to do anything special to support extensions to their classes. Our solution is efficient because the client is able to statically bind to the newly added fields and methods at compile-time. The solution is seamless for the extension writer because extensions are assemblies themselves and for the client because they are able to use the transformed assembly as they would any other assembly.

More information
For more information read the complete whitepaper or visit http://www.cs.columbia.edu/~eaddy/wicca.