| Chambers, C., Dean, J. & Grove, D. (1996), Wholeprogram optimization of object-oriented languages, Technical Report TR-96-06-02, University of Washington, Seattle, Washington 981952350 USA. |
.... improving cache locality [87, 117, 48, 128, 127] or traditional optimizations [35, 34, 36, 23] Profile driven optimizations have shown up in recent commercial products [89, 88, 131] There has been work on using profile information in dynamic compilers for Scheme [18, 17, 19] Self [61] Cecil [26] and ML [96, 101] More recently, the upcoming HotSpot dynamic compiler for Java claims to perform profile driven optimizations [84] 2.4 Dynamic code specialization The SELF Compiler [28, 133, 27] was the first system to incorporate automatic code specialization. SELF is a completely ....
C. Chambers, J. Dean, and D. Grove. Whole-program optimization of objectoriented languages. Technical Report TR-96-06-02, University of Washington, January 28, 1997.
....where the inlining is invalidated by further class loading. When such a scenario occurs, run time compilation has to be performed. There has been also work on techniques for inlining virtual methods more efficiently [6, 15, 25] Typically, static compilers use global or whole program analysis [4] to do inlining or devirtualization. However, without the ability to perform compilation at runtime, they assume that no changes will be made to classes referred to by the compiled code. Hence, they do not comply with the JLS. The trade off between binary compatibility (for full compliance with ....
D. Chambers, C. Dean, J. Grove. Whole-program optimization of object-oriented languages. Technical Report TR-96-06-02, Dept. of Computer Science and Engineering, University of Washington, 28, 1997.
....links with an existing implementation of the Java run time library, trusting the existing implementation to handle garbage collection, multi threading, I O, and graphics. It also relies on the Java run time library to automatically interface compiled code with dynamically loaded code. Vortex [2] also generates C code, but at a very low level. Vortex has front ends for Java, Cecil, C , and Modula 3. It implements a wide range of advanced optimizations and has served as a test bed for examining the e#ects of combining these optimizations. Unfortunately, the Java front end is still very ....
C. Chambers, J. Dean, and D. Grove. Wholeprogram optimization of object-oriented languages. Technical Report 96-06-02, Department of Computer Science, University of Washington, June 1996. 9
....freedom to develop flexible, extensible object oriented programs, without worrying about the performance. This enables the programmers to concentrate on the overall design and extensibility of the program without forcing them to introduce performance design trade offs. Whole program compilation [37, 27] is too restrictive for Java. Such a model produces programs that are either non portable (by generating machine code at the client side) or completely inflexible (by generating closed programs at the server side) The almostwhole program compilation model eliminates this problem by introducing a ....
....language compilation, functional languages and classical compilers. That work forms a background for the techniques described later in this thesis. 2. 4 Related Work This thesis is largely based on combining the work that has been done on compiler optimizations for object oriented languages [1, 28, 27, 28, 36, 37, 55, 64], functional languages [42, 54, 56, 66, 68] and compilers for vector and parallel machines [40, 48, 69] as 16 well as some techniques from classical scalar compilers [14, 30] The unique paradigm compiling for the Internet that Java has imposed on compiler research has allowed us to explore ....
[Article contains additional citation context not shown here]
Craig Chambers, Jeffrey Dean, and David Grove. Whole-program optimization of object-oriented languages. Technical Report TR-96-06-02, Department of Computer Science and Engineering, University of Washington, June 1996.
....code elimination. Spike [16] 17] optimizes executables for the Alpha NT environment. It concentrates on global register allocation and global code layout: using pro le information a code layout is produced using so called hot cold optimizations to improve cache behavior. MLD [18] and Vortex [19] are two whole program optimizers for object oriented languages. They focus on reducing the overhead created by virtual method invocation. Looking at the whole class hierarchy of a program, some of the virtual method invocations can be replaced by direct ones. These systems also reduce the ....
G. Chambers, J. Dean, and D. Grove, \Whole-program optimization of object-oriented languages," Tech. Rep. 96-06-02, Department of Computer Science and Engineering, University Of Washington, June 1996. ## ###### ## #### ############# ############ ## ###### ########### #
....[1995] evaluate type hierarchy analysis for Modula 3 and Cecil respectively. They find that type hierarchy analysis is a worthwhile technique that resolves many method invocations. Our work confirms these results. In addition to type hierarchy analysis, we evaluate a range of other techniques. Chambers et al. 1996] describe and evaluate a range of transformations and analyses for resolving method invocations in object oriented languages. Their paper combines many of the ideas in other papers discussed in this Related Works section; it also serves as an excellent overview of the area. Specifically, Chambers ....
CHAMBERS, C., DEAN, J., AND GROVE, D. 1996. Whole-program optimization of object-oriented languages. Tech. Rep. 96-06-02, University of Washington, Seattle, Washington. June.
....and Java applications. A large collection of work addresses optimizations specific to object oriented languages, such as class analysis, both intraprocedural [8] and interprocedural (see related work in [15] class hierarchy analysis and optimizations [22, 20] 9 receiver class prediction [13, 16, 7], method specialization [22] and call graph construction (see related work in [15] Other optimizations relevant to Java include bounds check elimination [18] and semantic inlining [23] 6 Conclusions The use of Java in many important server applications brings with it several requirements ....
Craig Chambers, Jeffrey Dean, and David Grove. Whole-program optimization of object-oriented languages. Technical Report UW-CSE-96-06-02, University of Washington, Department of Computer Science and Engineering, June 1996.
....of the new techniques built into the Self compilers are for resolving method invocations to direct calls. Unlike our work which focuses solely on analysis, the vast majority of the method resolution techniques in the Self compilers are based on transformations, such as code duplication. Vortex [22] is a whole program optimizer used to optimize Cecil [20] programs. Cecil is also a pure object oriented language, and thus a focus of this work, like that of the Self compilers, is to resolve method invocations. Vortex incorporates many techniques that are similar or identical to ours, such as ....
....ffl Unlike prior work, we directly address the issues in doing cross module optimization without the whole program being present. Prior work assumes that the entire program is available to the optimizer, which is an unrealistic assumption in many real world situations. ffl Unlike Chambers et al. [21, 22] and Holzle [56] which optimize dynamically typed pure object oriented languages, we optimize statically typed hybrid object oriented languages. The two kinds of languages encourage different programming styles and thus results for one kind of language may not apply to the other kind of language. ....
[Article contains additional citation context not shown here]
Chambers, C., Dean, J., and Grove, D. Whole-program optimization of object-oriented languages. Technical Report 96-06-02, University of Washington, Seattle, Washington, June 1996.
....CHA. Table 4 presents this information for the Javac compiler. It shows that our CHA allows 38 of the virtual call points to be transformed into procedure calls. Previous Work in CHA Compilers for other object oriented languages have included a CHA to optimize dynamically dispatched calls. In [24], Vortex, an optimizing compiler for object oriented languages is presented. Vortex differs from Salsa in the following ways. It is a language independent compiler with front ends for Cecil, C , and Modula 3. The target code it produces is machine code. The optimizations it performs range from ....
C. Chambers, J. Dean, and D. Grove. Whole-program optimization of object-oriented languages. Technical Report 96-06-02, Department of Computer Science, University of Washington, June 1996.
....[1995] evaluate type hierarchy analysis for Modula 3 and Cecil respectively. They find that type hierarchy analysis is a worthwhile technique that resolves many method invocations. Our work confirms these results. In addition to type hierarchy analysis, we evaluate a range of other techniques. Chambers et al. 1996] describe and evaluate a range of transformations and analyses for resolving method invocations in object oriented languages. Their paper combines many of the ideas in other papers discussed in this related works section; it also serves as an excellent overview of the area. Specifically, Chambers ....
CHAMBERS, C., DEAN, J., AND GROVE, D. 1996. Whole-program optimization of object-oriented languages. Tech. Rep. 96-06-02, University of Washington, Seattle, Washington. June.
....type hierarchy analysis for Modula 3 and Cecil respectively. They find that type hierarchy analysis is a worthwhile technique that resolves many method invocations. Our work confirms these results. In addition to type hierarchy analysis, we evaluate a range of other techniques. Chambers et al. [Chambers et al. 1996] describe and evaluate a range of transformations and analyses for resolving method invocations in object oriented languages. This paper combines many of the ideas in other papers discussed in this related works section. This paper also serves as an excellent overview of the area. They do not ....
Chambers, C., Dean, J., and Grove, D. 1996. Whole-program optimization of object-oriented languages. Tech. Rep. 96-06-02, University of Washington, Seattle, Washington. June.
....the context of Java like languages. As a language, Java allows for the separate compilation of classes which precludes the compiler from having complete information about the class hierarchy, as well as complete interprocedural information. For this reason we have adopted a whole program approach [4], wherein we require that all of the source for the program be accessible. Our algorithm handles recursive functions, side effects resulting from a function call (when an object is passed to a function and its data members are modified) the java inheritance model and composition of classes if it ....
C. Chambers, J. Dean, and D. Grove. Whole-program optimization of object-oriented languages. Technical report, University of Washington, 1996.
....not yet that sophisticated, but they harvest (we believe) a major portion of the benefit from more elaborate approaches. Our future plans include several fairly standard optimizations. We will add local optimizations based on SSA form[4,11, 14] We will also upgrade our class hierarchy analysis[3]. We believe there are synergistic possibilities in the combination of these technologies; for example, the inheritance tree can serve (with slight modification) as the lattice in the Wegman Zadeck constant propagation 124 algorithm[14] We also intend to make further optimizations with regard to ....
Chambers, C., Dean, J., and Grove, D. Whole-program optimization of objectoriented languages. Tech. Rep. 96-06-02, University of Washington, June 1996. http://www.cs.washington.edu/research/projects/cecil/cecil/www/Papers/wholeprogram. html.
....predictor considers the call chain at the time of the object s creation. This predictor will be harder to implement, but uses more context sensitive information about the object allocated and therefore tends to make better predictions. This kind of optimization is referred to as k CCP by Chambers [4] (where k is the stack depth used) The depth the predictor looks to is of particular importance with this predictor. If the depth is set too deep, the predictor can overspecialize the prediction and not generate something that is useful across data sets. If the depth is not set deep enough the ....
....predictor makes the predictions more specialized and thus less capable of generalizing between program inputs. As described by Chambers et al. as the amount of context increases, the precision of the distributions increases, but the applicability of the distributions decreases : [4][p 25] On the other hand, with respect to calls to malloc, we know that many applications hide malloc behind application specific abstractions, and thus in many cases some context is needed. Figure 5 illustrates the effect of varying the stack depth from one to five in the Stack Depth predictor ....
Craig Chambers, Jeffrey Dean, and David Grove. Whole-program optimization of object-oriented languages. Technical Report UW-CSE-96-06-02, University of Washington Department of Computer Science and Engineering, Seattle, WA, 1996.
....links with an existing implementation of the Java runtime library, trusting the existing implementation to handle garbage collection, multi threading, I O, and graphics. It also relies on the Java run time library to automatically interface compiled code with dynamically loaded code. Vortex [2] also generates C code, but at a very low level. Vortex has frontends for Java, Cecil, C , and Modula 3. It implements a wide range of advanced optimizations and has served as a test bed for examining the effects of combining these optimizations. Unfortunately, the Java front end is still very ....
C. Chambers, J. Dean, and D. Grove. Whole-program optimization of object-oriented languages. Technical Report 96-06-02, Department of Computer Science, University of Washington, June 1996.
....predictor considers the call chain at the time of the object s creation. This predictor will be harder to implement, but uses more context sensitive information about the object allocated and therefore tends to make better predictions. This kind of optimization is referred to as k CCP by Chambers [4] (where k is the stack depth used) The depth the predictor looks to is of particular importance with this predictor. If the depth is set too deep, the predictor can overspecialize the prediction and not generate something that is useful across data sets. If the depth is not set deep enough the ....
....predictor makes the predictions more specialized and thus less capable of generalizing between program inputs. As described by Chambers et al. as the amount of context increases, the precision of the distributions increases, but the applicability of the distributions decreases . [4][p 25] On the other hand, with respect to calls to malloc, we know that many applications hide malloc behind application specific abstractions, and thus in many cases some context is needed. Figure 5 illustrates the e#ect of varying the stack depth from one to five in the Stack Depth predictor ....
Craig Chambers, Je#rey Dean, and David Grove. Whole-program optimization of object-oriented languages. Technical Report UW-CSE-96-06-02, University of Washington Department of Computer Science and Engineering, Seattle, WA, 1996.
....program construction using encapsulation. While this helps reuse, rapid development and debugging, it also entails well known performance problems [2, 5] To implement encapsulation efficiently, modern optimizing compilers perform inlining, interprocedural analysis and interprocedural optimization [3]. Unfortunately, such techniques do not easily generalize to a setting where modules can be replaced at runtime. In this paper, we propose the technique of module merging to allow interprocedural optimization of code that can be replaced at runtime. Code modules are merged and tests inserted to ....
C. Chambers, J. Dean, D. Grove. Whole-Program Optimization of ObjectOriented Languages. Technical report 96-06-02, Department of Computer Science and Engineering, University of Washington, 1996.
No context found.
Craig Chambers, Jeffrey Dean, and David Grove. Whole-Program Optimization of Object-Oriented Languages. Technical Report UW-CSE-96-06-02, Department of Computer Science and Engineering. University of Washington, June 1996.
....potential targets of a virtual call, compilers can perform various forms of guarded inlining. The compiler can decide which targets to speculatively inline at a call site using static heuristics [13, 8] pro le information [24, 21] and or static examination of the program s class hierarchy [7, 11]. Jalape no uses both class tests and method tests [12] to perform guarded inlining of virtual calls based on both class hierarchy analysis and on line pro le information. 10 In addition to determining which calls are legal to inline, the compiler must identify a set of call sites as attractive ....
C. Chambers, J. Dean, and D. Grove. Whole-program optimization of object-oriented languages. Technical Report UW-CSE-96-06-02, Department of Computer Science and Engineering. University of Washington, June 1996.
.... can be driven either by information hard wired into the compiler, as in early Smalltalk and Self implementations [Deutsch Schiffman 84, Chambers Ungar 89] or by profile derived class distributions [Hlzle Ungar 94, Grove et al. 95] or by static examination of the program s class hierarchy [Chambers et al. 96] We use the term exhaustive class testing to refer to class hierarchy guided class testing, and profile guided class prediction to refer to class testing based on dynamic profile information. If a large number of receiver classes are possible at a call site, testing for individual classes can ....
Craig Chambers, Jeffrey Dean, and David Grove. Whole-Program Optimization of Object-Oriented Languages. Technical Report TR-96-06-02, Department of Computer Science and Engineering. University of Washington, June 1996.
No context found.
Chambers, C., Dean, J. & Grove, D. (1996), Wholeprogram optimization of object-oriented languages, Technical Report TR-96-06-02, University of Washington, Seattle, Washington 981952350 USA.
No context found.
Craig Chambers, Je#rey Dean, and David Grove. Whole-program optimization of object-oriented languages. Technical Report 96-0612 02, Department of Computer Science and Engineering, University of Washington, Jun 1996.
No context found.
C. Chambers, J. Dean, and D. Grove. Wholeprogram optimization of object-oriented languages. Technical Report UW-CSE-96-06-02, University of Washington, Department of Computer Science and Engineering, June 1996.
No context found.
C. Chambers, J. Dean, and D. Grove. Wholeprogram optimization of object-oriented languages. Technical Report UW-CSE-96-06-02, University of Washington, Department of Computer Science and Engineering, June 1996.
No context found.
Craig Chambers, Jeffrey Dean, and David Grove. Whole-Program Optimization of Object-Oriented Languages. University of Washington, Technical Report 96-06-02, June 96.
First 50 documents
Online articles have much greater impact More about CiteSeer.IST Add search form to your site Submit documents Feedback
CiteSeer.IST - Copyright Penn State and NEC