Enhancing Source-Level Programming Tools with An Awareness of ...

More documents

Recommendations

Info

the changes in data values and code location. A significantamount of research aims at the problem of debugging optimizedcode [20, 21, 7, 27, 16, 9, 18]. The proposed solutionsenable source-level debuggers to display the informationabout an optimized program, as if the original (unoptimized)version of the code was being debugged.The techniques for debugging optimized code deal withthe challenges arising as a result of optimizing compilerstransforming intermediate code to improve performance.While these transformations can be quite extensive, theyare usually confined to method bodies and do not alterthe debugged program’s semantics. By contrast, structuralenhancement aims at larger-scale program transformationsthat can add new classes and interfaces to a program. Thus,source level debugging of structurally enhanced programsrequires different debugging techniques such as the presentedsymbolic undo.Debugging for AOP. Aspect-Oriented Programming(AOP) [24] can be viewed as an enhancement technology,and several approaches aim at debugging support forAOP [14, 34, 22]. However, debugging aspect-oriented programsis different from debugging transparently enhancedprograms. AOP provides a domain-specific language forprogramming enhancements such as AspectJ [23], and anAOP debugger traces the bytecode generated by AspectJ toits aspect source file. By contrast, transparent bytecode enhancementshave no source code representation. Thus, theapproaches to debugging AOP software cannot be applied todebugging transparently enhanced programs.In addition, AspectJ as a language cannot express all thestructural enhancement transformations. For example, it isimpossible to express in AspectJ that the name of a programconstruct (e.g., class, field, or method) be changed. AspectJdoes not provide facilities for removing a program construct,something that program enhancers need to do on a regularbasis. For example, the split class enhancement movesfields from a class to another class, thus removing them fromthe original class. Finally, program enhancers often generatenew classes and interfaces and reference them in the enhancedprogram. AspectJ is not designed for expressing howto generate a new class, whose structure is based on some existingprogram construct. Thus, we could not have used AspectJinstead of SER to represent structural enhancements.5.2 Program Transformation LanguagesSER is a domain-specific language for expressing how bytecodeis enhanced structurally. Other domains also featuredomain-specific languages for expressing program transformations.JunGL [48], a domain-specific language for refactoring,combines functional and logic query language idioms.JunGL represents programs as graphs and manipulates refactoringsvia graph transformations. The language providespredicates to facilitate the querying of graph structures.JunGL uses demand-driven evaluation to prevent scriptsfrom becoming prohibitively complex.Sittampalam et al. [39] specify program transformationsdeclaratively and generate executable program transformersfrom specifications. The Prolog language is augmented withfacilities for incremental evaluation of regular path queries.The augmented language is used to specify program transformationsby expressing a program and its transformedcounterpart. The transformations can be combined with astrategy script, based on Stratego [49], to specify the traversalsof a program and the order of the transformations.Whitfield and Soffa’s code-improving transformationframework consists of a case tool and a specification language[50]. The specification language, called Gospel, declaresprogram transformations; the case tool, called Genesis,generates a program transformer given a Gospel specification.A Gospel script consists of a declaration section,containing variables declarations, a precondition section,containing code pattern descriptions and control dependenceconditions, and an action section, containing a set of transformationoperations.The Coccinelle [41] tool introduces the SmPL languagefor locating and automatically fixing bugs. SmPL programsspecify how in response to some runtime condition, a programshould be transformed to fix a bug and log the changes.FSMLs [10] is a domain specific modeling language fordescribing the framework-provided knowledge, includingframework instantiation, procedures for implementing interfaces,and proper usage of framework services. FSMLsbears similarity to our approach in its ability to provide a bidirectionalmapping between framework features and theirabstract representation.JAVACOP [1] introduces a declarative rule languagefor expressing programmer-defined types, called pluggabletypes. The types are described as user-defined rules, whichJAVACOP uses for transforming the abstract syntax tree of aprogram.Because these program transformation languages weredesigned specifically for their respective domains, we couldnot have used any of them for our purposes. The main designgoal of our SER language was to be able to expressstructural enhancements used by bytecode enhancers declarativelyand to provide special constructs for domain-specifictransformations such as adding getter/setter methods.5.3 Program DifferencingSER scripts describe generalized structural program differences.Program differencing is an active research area andseveral new differencing algorithms have been proposed recently.Previtali et al.’s technique [35] generates version differencesof a class at bytecode level. Their algorithm producesthe information on added, removed, or modified classes.Dmitriev incorporates program change history into a Javamake utility that selectively recompiles dependent sourceAccepted to OOPSLA 2009 14 2009/5/14
files [12]. The JDIFF [3] algorithm identifies changes betweentwo versions of an object-oriented program using anaugmented representation of a control-flow graph. M. Kimet al. [25] infer generalized structural changes at or abovethe level of a method header, represented as first-order relationallogic rules. These techniques could be leveraged togenerate SER scripts automatically by generalizing the differencesbetween the original and enhanced versions of multipleclasses.Our own Rosemari system [45] generalizes structural differencesbetween two versions of a representative example.Such examples are usually supplied by framework vendorsto guide the developers in upgrading their legacy applicationsfrom one framework version to another. Rosemari featuresa DSL for describing program transformations, but canbe retargeted to present structural changes in SER instead.5.4 Symbolic ExecutionThe idea of symbolic undo, used in implementing our debugger,is influenced by symbolic execution [26], which analyzesa program by executing it with symbolic inputs, butwithout actually running it. By analogy, our symbolic undotechnique enables source level debugging of enhanced bytecodeby mapping it back, via symbolic operations, to its originalsource code, also without affecting the program’s execution.6. Future WorkThe initial evaluation results of our approach have been positive.To demonstrate the effectiveness of our approach, wehave conducted two case studies. Specifically, we have augmentedtwo source-level programming tools with enhancement-awareness,so that the tools could handle programs thatuse four different bytecode enhancement strategies.As future work, we plan to conduct user studies to evaluatethe value of our approach for programmers with differentlevels of expertise. One such study could evaluate whether asymbolic undo debugger is more effective than a regular debuggerin helping the programmer to locate and fix bugs.Another study could evaluate the value of integrating the enhancementinformation with a programming editor.We plan to create a debugger for SER scripts. Althoughthe declarative nature of SER scripts makes it easier to ensuretheir correctness, bugs still can be introduced, particularlyif a SER script is developed by someone other than aframework developer. Having a SER debugger is likely toimprove the usability of our approach.We plan to extend our approach to programs that havebeen transparently enhanced more than once, possibly bydifferent enhancers. For example, the same application canuse multiple frameworks, each enhancing intermediate codein its own way.Bytecode enhancement could add functionality in languagesother than the host language, including query languagessuch as SQL or Datalog. Our approach would haveto be extended to add the enhancements-awareness to programmingtools handling multi-language applications.There could be potential benefit in synthesizing thesource code representation of bytecode-only enhancements.To that end, the SER interpreter would have to be integratedwith a decompiler that is enhancements-aware. The successof this approach would mainly depend on the decompiler’sefficiency and precision.Generating SER scripts automatically will reduce theframework programmer’s effort and make our methodologymore appealing to the average programmer. A promising approachwould require generalizing program differencing, atarget of several recent research efforts [25].Finally, we would like to make our symbolic debuggeravailable as an Eclipse IDE plug-in.7. ConclusionsThis paper has argued about the value of enhancing sourcelevelprogramming tool with an awareness of transparentprogram transformations. To enable such awareness, wehave introduced SER, a declarative language that conciselydescribes structural enhancements. To validate our approach,we have augmented two existing source-level programmingtools with an awareness of bytecode enhancement. We havealso expressed in SER four enhancement strategies followedby different enhancers and used our augmented programmingtool to handle the enhanced programs. As part of enhancinga source level debugger, we have introduced a newdebugging architecture that makes it possible to calculatereverse-mapping instructions based on a SER specification.Bytecode enhancement has already entered the mainstreamof enterprise software development, and future enhancersare likely to transform programs in even more complexways. As a result, source code alone will become evenless sufficient in presenting a realistic picture about the functionalityof a program. Our approach of making programmingtools aware of bytecode enhancements has the potentialto address this problem, and help programmers enjoythe benefits of transparent bytecode enhancement withoutsuffering any of its disadvantages.AvailabilityAll the software described in the paper is available from:http://research.cs.vt.edu/vtspaces/ser/.References[1] C. Andreae, J. Noble, S. Markstrum, and T. Millstein.A framework for implementing pluggable type systems.SIGPLAN Not., 41(10):57–74, 2006.[2] Apache Jakarta Project. The Byte Code Engineering Library.http://jakarta.apache.org/bcel/manual.html.Accepted to OOPSLA 2009 15 2009/5/14
Page 1 and 2: Enhancing Source-Level Programming
Page 3: The rest of this paper is structure
Page 6 and 7: AddClass(〈C〉p, 〈C + 〉p) =
Page 8 and 9: 01020304050607080910111213141516171
Page 10 and 11: play the original source code, undo
Page 12 and 13: ASTWalkerJavaSource1: input5: retur
Page 16 and 17: [3] T. Apiwattanapong, A. Orso, and

Enhancing Source-Level Programming Tools with An Awareness of ...

Create successful ePaper yourself

Delete template?

Save as template?