Ph.D. Candidacy ExamMarc Eaddy

November 2, 2005

Committee:Alfred Aho

Stephen Edwards

Angelos Keromytis

Program Transformation

2

Motivation• Increase programmer productivity by

automating programming tasks

• Enable programming at a higher-level of abstraction

• Increase efficiency, maintainability and reusability

Source: A Survey of Rewriting Strategies in Program Transformation Systems, Eelco Visser (2001)

3

My research interestBelief

Some types of functionality can only be added to a program effectively by using

• "semantics-altering" program transformations• offline program transformations that will be

performed online

ProblemSemantics-altering and dynamic program transformation technology is not sufficiently mature enough to enjoy widespread use

4

Program transformation• Program – an organized list of

executable instructions specified using a programming language

• The structure of a program allows us to transform it (P P’)

5

Characteristics• Transformation type

• Translation – different source/target languages• Rephrasing – same source/target language

• Program representation• Text• Abstract-Syntax Tree• Intermediate Representation• etc.

• Implementation strategy• Rewrite systems• Meta-programming• Manual programming• etc.

6

Translation• Synthesis – lowers the level of abstraction

• Refinement• Compilation

• Reverse engineering – raises the level of abstraction• Decompilation• Architecture extraction• Documentation generation• Software visualization

• Migration – same level of abstraction• Analysis – reduces a program to one aspect

• Control-flow analysis• Data-flow analysis

Source: A Survey of Rewriting Strategies in Program Transformation Systems, Eelco Visser (2001)

7

Rephrasing• Normalization – decreases syntactic complexity

• Simplification• Desugaring

• Instrumentation – adds functionality• Profiling• Weaving

• Optimization – improves resource utilization• Specialization• Inlining• Fusion

• Refactoring – improves/degrades understanding• Design improvement• Obfuscation

• Renovation – fixes errors• Evolution – manual modifications

Source: A Survey of Rewriting Strategies in Program Transformation Systems, Eelco Visser (2001)

8

Program transformation is immature

• Not well supported by commodity languages• No native language constructs• Requires external tools• Must workaround language issues

• Weakly typed languages (e.g., C)

• Not well integrated with software development tools• e.g., Editors, Debuggers

• Not well integrated with the software development process• e.g., Requirements, Design, Build, Testing, Servicing

• Not well integrated with runtime environments• Dynamic updates not well supported• Debug information gets out of sync

• Not reliable enough• Verification• Validation

9

My research focus• Two areas of program transformation

that are very promising but currently immature• Aspect-Oriented Programming (AOP)

(application)• Dynamic Software Updating (DSU)

(enabling technology)

• Contribution goals• Identify and solve some of the research

problems• Design a general framework• Instantiate a framework prototype

10

Aspect-oriented programming• Goal: Improve modularity of

crosscutting concerns

• AOP = Open Classes + Advice• Open Classes (type changes)• Advice (code changes)

11

AOP terminology• 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

12

Example: tracing aspectusing Phx.Morph.Aop;using Phx.Morph.Attributes;

public class TracingAspect{ [Advice(AdviceType.before, "call(System.Reflection..)")] static public void Log([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}]", filePath, line); }}

13

Weaved result IL_0065: ldarg.0

IL_0066: call class System.Reflection.Assembly System.Reflection.Assembly::Load(string)

14

Weaved result IL_0065: ldarg.0 IL_0066: ldstr "System.Reflection.Assembly.Load" IL_006b: ldstr

"Phx.Morph.ReflectionHelpers.LoadAssembly" IL_0070: ldstr "ReflectionHelpers.cs" IL_0075: ldc.i4 0xfb IL_007a: call void TraceAspect::Log(string, string, string,

uint32) IL_007f: call class System.Reflection.Assembly

System.Reflection.Assembly::Load(string)

Injected code

15

AOP immaturity• Syntactically based

• Fragile• Hard to reuse

• Usually requires invasive transformation of the original source code or binary code• Can be inefficient• Hard to implement• Can confuse the debugger and the programmer

• Limited tool support and integration• Limited user interface support• Limited visualization capability• Reduced debug capability

• Difficult to support• Introduces new fault models• Hard to understand• Complicates versioning• Hard to isolate faults and attribute blame• Requires extra coordination with independent software vendors

16

Dynamic software updating• Goals

• Postpone transformations until runtime when we have more information

• Avoid downtime

• Problems• How can we update the code and data of a

running program?• How do we do it “safely”?• What are the limitations?

17

DSU applications• Dynamic Aspect-Oriented Programming• Online Software Evolution

• Online Security Patching• Edit-and-Continue• Open Classes

• Optimization• Adaptive Dynamic Optimization• Dynamic Deoptimization

• Reactive Systems• Self-Healing Software

• Testing

18

Mutatis mutandis paper"The necessary changes having been made,

with respective differences taken into consideration"

• Shows that updates can be provably strongly type safe• What can be updated and when• Can be determined statically!

• Working to generalize results to C• Examples: vsftpd, apache, opensshd

• But current analysis framework is too conservative• Aliasing• Unsafe casts of function pointers

Source: Mutatis Mutandis: Safe and Predictable Dynamic Software Updating, Stoyle, Hicks, Bierman, Sewell, Neamtiu (2005)

19

let dispatch(s : req) : handResult = let t = decode((conreq s).fd) in let u1 = update in if (confdtype t) = Socket then

let k = getsock((conreq s).fd) in let flags = decode_sockopargs((conreq s).rest, (conreq s).op) in

let h = getsockhandler((conreq s).fd, (conreq s).op) in let u2 = update in let res = (consockhandler h)(k, (conreq s).buf, flags) in let u3 = update in res else if (confdtype t) = File then . . .

else (abshandResult −1)

Example Proteus program

Source: Mutatis Mutandis: Safe and Predictable Dynamic Software Updating, Stoyle, Hicks, Bierman, Sewell, Neamtiu (2005)

20

DSU immaturity• Limited virtual machine support

• Java: HotSwap API• Class-based: too coarse-grained, inefficient• Can't update active functions

• .NET: Edit-and-Continue API• Limited functionality• Debug-only, inefficient• Patches are hard to specify

• Limited tool support and integration• Limited user interface support• Reduced debug capability

• Difficult to support• Complicates versioning

21

Conclusion• Program transformation is a powerful

paradigm but is still immature• Language and tool support• Runtime environment support• Software process integration• Serviceability

• I am looking at the research problems that hinder maturity for two areas• Aspect-Oriented Programming• Dynamic Software Updating

22

Thank you!