Object-oriented programming languages promise to improve programmer productivity by supporting abstract data types, inheritance, and message passing directly within the language. Unfortunately, traditional implementations of object-oriented language features, particularly message passing, have been much slower than traditional implementations of their non-object-oriented counterparts: the fastest existing implementation of Smalltalk-80 runs at only a tenth the speed of an optimizing C implementation. The dearth of suitable implementation technology has forced most object-oriented languages to be designed as hybrids with traditional non-object-oriented languages, complicating the languages and making programs harder to extend and reuse. This dissertation describes a collection of implementation techniques that can improve the run-time performance of object-oriented languages, in hopes of reducing the need for hybrid languages and encouraging wider spread of purely object-oriented langu...

Object-oriented programming languages confer many benefits, including abstraction, which lets the programmer hide the details of an object’s implementation from the object’s clients. Unfortunately, crossing abstraction boundaries often incurs a substantial run-time overhead in the form of frequent procedure calls. Thus, pervasive use of abstraction, while desirable from a design standpoint, may be impractical when it leads to inefficient programs. Aggressive compiler optimizations can reduce the overhead of abstraction. However, the long compilation times introduced by optimizing compilers delay the programming environment‘s responses to changes in the program. Furthermore, optimization also conflicts with source-level debugging. Thus, programmers are caught on the horns of two dilemmas: they have to choose between abstraction and efficiency, and between responsive programming environments and efficiency. This dissertation shows how to reconcile these seemingly contradictory goals by performing optimizations lazily. Four new techniques work together to achieve high performance and high responsiveness: • Type feedback achieves high performance by allowing the compiler to inline message sends based on information extracted from the runtime system. On average, programs run 1.5 times faster than the previous SELF system; compared to a commercial Smalltalk implementation, two medium-sized benchmarks run about three times faster. This level of performance is obtained with a compiler that is both simpler and faster than previous SELF compilers. • Adaptive optimization achieves high responsiveness without sacrificing performance by using a fast nonoptimizing compiler to generate initial code while automatically recompiling heavily used parts of the program with an optimizing compiler. On a previous-generation workstation like the SPARCstation-2, fewer than 200 pauses exceeded 200 ms during a 50-minute interaction, and 21 pauses exceeded one second. On a currentgeneration workstation, only 13 pauses exceed 400 ms. • Dynamic deoptimization shields the programmer from the complexity of debugging optimized code by transparently recreating non-optimized code as needed. No matter whether a program is optimized or not, it can always be stopped, inspected, and single-stepped. Compared to previous approaches, deoptimization allows more debugging while placing fewer restrictions on the optimizations that can be performed. • Polymorphic inline caching generates type-case sequences on-the-fly to speed up messages sent from the same call site to several different types of object. More significantly, they collect concrete type information for the optimizing compiler. With better performance yet good interactive behavior, these techniques make exploratory programming possible both for pure object-oriented languages and for application domains requiring higher ultimate performance, reconciling exploratory programming, ubiquitous abstraction, and high performance.

We consider the problem of supporting compacting garbage collection in the presence of modern compiler optimizations. Since our collector may move any heap object, it must accurately locate, follow, and update all pointers and values derived from pointers. To assist the collector, we extend the compiler to emit tables describing live pointers, and values derived from pointers, at each program location where collection may occur. Significant results include identification of a number of problems posed by optimizations, solutions to those problems, a working compiler, and experimental data concerning table sizes, table compression, and time overhead of decoding tables during collection. While gc support can affect the code produced, our sample programs show no significant changes, the table sizes are a modest fraction of the size of the optimized code, and stack tracing is a small fraction of total gc time. Since the compiler enhancements are also modest, we conclude that the approach is...

Optimizing compilers produce code that impedes source-level debugging. Examples are given in which optimization changes the behavior of a program even when the optimizer is correct, showing that in some circumstances it is not possible to completely debug an unoptimized version of a program. Source-level debuggers designed for unoptimized code may mislead the debugger user when invoked on optimized code. One situation that can mislead the user is a mismatch between where the user expects a breakpoint to be located and the breakpoint's actual location. A mismatch may occur due to statement reordering or discontiguous code generated from a statement. This work describes a mapping between statements and breakpoint locations that ameliorates this problem. The mapping enables debugger behavior on optimized code that approximates debugger behavior on unoptimized code closely enough that the user need not make severe changes in debugging strategies. Another situation that can mislead the us...

SPAWAR under contract N00039-93-C-0152. The views and conclusions contained in this document are those of the authors and should not be interpreted as representing the official policies, either expressed or implied, of the U.S. Government. Keywords: Source-level debugging, compiler optimization, code generation, nonresident variables, endangered variables, suspect variables, noncurrent variables Compiler optimizations play a crucial role in the performance of modern computer systems. Debugger technology, however, has lagged behind in its support of optimizations. Debugging the unoptimized translation is often impractical, so handling of optimized code by the debugger is necessary. But compiler optimizations make it difficult to provide sourcelevel debugger functionality: When a program is compiled with optimizations, mappings between breakpoints in the source and object code become complicated, and values of variables may be either inaccessible in the runtime state or inconsistent with what the user expects at a breakpoint. Although researchers and implementors have long acknowledged the need for source-level debugging of optimized code, compiler developers have generally

.......................................................................................................... viii CHAPTER 1. Compiler Optimizations And Debugging .............................. 1 Introduction.......................................................................................... 1 Debuggers for Non-Optimized Imperative Programs............................. 2 Some examples of debug information usage. ......................................... 3 A Program Exception................................................................ 3 Setting a Breakpoint.................................................................. 3 Starting Execution Under User Control ..................................... 4 Reporting the Value of a Program Variable ............................... 4 Changing the Value of a Program Variable ................................ 4 How optimizations can cause problems for debuggers........................... 5 Constant Folding......................................

This paper describes alternative ways to support this facility in the circumstance that this code is optimized away. Categories and Subject Descriptors: D.2.5 [Software Engineering]: Testing and Debugging --- debugging aids; D.2.6 [Software Engineering]: Programming Environments; D.3.4 [Programming Languages ]: Processors --- code generation, compilers, optimization

This paper describes a mapping between statements and breakpoint locations that ameliorates this problem. The mapping enables debugger behavior on optimized code that approximates debugger behavior on unoptimized code sufficiently closely for the user to use traditional debugging strategies. Optimization can also cause the value of a variable to be noncurrent --- to differ from the value that would be predicted by a close reading of the source code. This paper presents a method of determining when this has occurred, and shows how a debugger can describe the relevant effects of optimization. The determination method is more general than previously published methods; it handles global optimization and many flow graph transformations, and it is not tightly coupled to optimizations performed by a particular compiler. Necessary compiler support is also described. Categories and Subject Descriptors: D.2.5 [Software Engineering]: Testing and Debugging --- debugging aids; D.2.6 [Software Engineering]: Programming Environments; D.3.4 [Programming Languages]: Processors --- code generation, compilers, optimization

Debuggers are critical tools for the software development. The design and implementation of a source-level debugging system that enables the HPF programmer to observe the behavior of the program at the level at which the program has been developed presents unique challenges. The main requirement put on an HPF debugger is to observe and control the state of many processors, to summarize and present distributed information in a concise and clear way in terms of the source program to the user. To be practical, the debugger has to support interactive source-level debugging of large-scale applications on large machines. In this paper we define design goals for HPF debuggers and present an architecture of an advanced HPF debugging system DeHiFo, which addresses several challenges involved and provides significant contributions to the existing debugging technology. The HPF debugger is a rather complex system. Its development requires a systematic cooperation between several partne...

SELF's debugging system provides complete source-level debugging (expected behavior) with globally optimized code. It shields the debugger from optimizations performed by the compiler by dynamically deoptimizing code on demand. Deoptimization only affects the procedure activations that are actively being debugged; all other code runs at full speed. Deoptimization requires the compiler to supply debugging information at discrete interrupt points; the compiler can still perform extensive optimizations between interrupt points without affecting debuggability. At the same time, the inability to interrupt between interrupt points is invisible to the user. Our debugging system also handles programming changes during debugging. Again, the system provides expected behavior: it is possible to change a running program and immediately observe the effects of the change. Dynamic deoptimization transforms old compiled code (which may contain inlined copies of the old version of the changed procedure) into new versions reflecting the current source-level state. To the best of our knowledge, SELF is the first practical system providing full expected behavior with globally optimized code.