Type Feedback for Bytecode Interpreters

Transcription

1 Type Feedback for Bytecode Interpreters Michael Haupt, Robert Hirschfeld, Marcus Denker To cite this version: Michael Haupt, Robert Hirschfeld, Marcus Denker. Type Feedback for Bytecode Interpreters. ICOOOLPS 2007, 2007, Berlin, Germany. pp.17-22, Proceedings of the Second Workshop on Implementation, Compilation, Optimization of Object-Oriented Languages, Programs and Systems (ICOOOLPS 2007). <inria > HAL Id: inria Submitted on 15 Jan 2011 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

2 Type Feedback for Bytecode Interpreters Position Paper ICOOOLPS 2007 Michael Haupt 1, Robert Hirschfeld 1, and Marcus Denker 2 1 Software Architecture Group Hasso-Plattner-Institut University of Potsdam, Germany 2 Software Composition Group Institute of Computer Science and Applied Mathematics University of Berne, Switzerland {michael.haupt,hirschfeld}@hpi.uni-potsdam.de, denker@iam.unibe.ch Abstract. This position paper proposes the exploitation of type feedback mechanisms, or more precisely, polymorphic inline caches, for purely interpreting implementations of -oriented programming languages. Using Squeak s virtual machine as an example, polymorphic inline caches are discussed as an alternative to global caching. An implementation proposal for polymorphic inline caches in the Squeak virtual machine is presented, and possible future applications for online optimization are outlined. 1 Introduction Bytecode interpreters are small in size and comparatively easy to implement, but generally execute programs much less efficiently than just-in-time (JIT) compilers. Techniques like threaded interpretation [9, 11, 2] focus on speeding up interpretation itself, and caching [4,5,1] improves the performance of message s the most common operation in -oriented software [7]. It is interesting to observe that, while threading mechanisms are used naturally to a varying degree in interpreter implementations, such systems usually employ only global caching to speed up dynamic dispatch. A global cache is clearly beneficial with respect to overall performance. Still, it does not provide optimal support for polymorphic message sites, and it does not allow for exploiting type information (we provide details on these issues in the following section). In our opinion, the employment of polymorphic inline caches (PICs) [5] instead can provide means for achieving significant speedups in interpreters while exhibiting only a moderate increase in memory footprint and implementation complexity. Proceedings of the Second Workshop on Implementation, Compilation, Optimization of Object-Oriented Languages, Programs and Systems (ICOOOLPS 2007), July 2007, ISSN , pp

3 In the next section, we briefly discuss global caches. The interpreter we use as a case study throughout this paper is that of the Squeak [8,12] virtual machine (VM) [13]. Section 3 proposes an approach to the implementation of PICs in the Squeak interpreter. Finally, section 4 gives a summary of the paper and an outlook on possible future optimizations in interpreters that are encouraged by the introduction of type feedback mechanisms. 2 Global Caching: Discussion The Squeak VM interpreter uses a global cache for improving lookup performance. This cache has a fixed size and maps <target class, > pairs to concrete implementations (compiled s). It significantly contributes to the overall performance of the Squeak interpreter. However, such a cache has several shortcomings. Since it is global, collisions are relatively frequent and lead to longer lookup times. The cache has to be flushed as soon as changes in the class hierarchy or in implementations occur. For changes in implementations, the cache is not entirely flushed, but only for the entries that refer to implementations of the in question. Moreover, flushing is required whenever the garbage collector performs heap compaction, as hashing is done based on target class and addresses. After a flush, the cache needs to be repopulated, during which and overall performance is lower. The global cache suffers from being global. It cannot react to local changes in an adequate way i.e., by an update operation that is quasi-local in its effect on cache contents. A local change, such as a class overwriting an inherited, actually affects only a small part of the entire class hierarchy. Nevertheless, lookup data for large parts of the class hierarchy needs to be restored. Also, the global cache is, due to its mapping scheme, generally not able to provide local information, that is information per site. Such information typically comprises of the concrete receiver types (classes) of a message at a given polymorphic site. It is called type feedback information [6] and is very interesting with regard to optimizations (cf.sec.4). The performance of the Squeak interpreter is good. Still, we believe that it can benefit from a caching mechanism that supports local type feedback. These so-called inline caches [4] are usually used in environments that employ JIT compilation and bring great benefit in terms of dynamic message dispatch performance. Inline caches store the most recently looked-up address at each given site. The address is cached at the site, replacing the call instruction to the lookup with a direct jump to the code of the. Since there is a jump to the cached, no lookup needs to be done at all. There is only a slight overhead resulting from a check at the beginning of the verifying that the class of the receiver is the correct one. In case the receiver class has changed, the standard lookup is used instead. Obviously, simple inline

4 caches are not an ideal solution for supporting polymorphic sites since they already fail if the same message is sent to an alternating list of s. PICs [5] store, for a given site, the addresses of N past message s, where N is the cache size. A PIC stores <receiver class, address> key-value pairs. The Strongtalk [14] VM is a prominent example of such an environment. It is comprised of a interpreter and a JIT compiler; the interpreter already stores type feedback information in PICs to speed up message ing. Information stored in these PICs is later exploited by JIT-compiled native code. 3 Polymorphic Inline Caching in Bytecode Interpreters We believe that PICs can be beneficial also in solely interpreting VM implementations, such as the Squeak VM [13]. In this section, we outline an implementation proposal for PICs in that environment. An interpreter does not generate binary code for s, thus PICs cannot store memory addresses of code. In Squeak, the is stored in compiled s. Here, PICs can store a reference to the compiled instead. The implementation affects both the Squeak VM and reflectively the Smalltalk image. At the image level, each Smalltalk is represented as an instance of the CompiledMethod class. The format of CompiledMethod instances needs to be modified to store site type feedback information. In the VM, the interpreter logic must be augmented to support storing and updating of said information. Squeak CompiledMethods have the layout shown in Fig.1. The standard provides information about the itself, its class, hash value, etc. The subsequent contains information on the in question, such as the number of arguments, local variables and literals. After that, there are several pointers to the s literals, each referencing a given constant occurring in the. For example, all s reference their (the name of the to call) as an offset in the literal frame. The array represents the code, and the trailer carries additional information about the s source code location.... literals s trailer... Fig. 1. Object layout of a Squeak CompiledMethod instance. For the PIC implementation in Squeak, the literals region in CompiledMethod instances is of special interest. In the current Squeak system, the compiler gen-

5 erates one slot in the literal frame for any unique. This means that s ing the same reference the same slot in the the literal array (cf.fig.1). The Smalltalk compiler needs to be modified to generate one entry in the literal array for each, without the sharing property mentioned above. Thus we have as many literal slots storing s as there are s in the CompiledMethod (cf.fig.2). Each of these slots can hold a reference to an carrying type feedback information. To this end, several dedicated classes (described below) are to be introduced into the image.... literals s trailer... Fig. 2. A CompiledMethod instance without sharing. Initially, all slots contain s. Once a site is visited by the interpreter and the corresponding message is sent, the is replaced by a reference to an inline cache (IC) (cf.fig. 3), an instance of the InlineCache class. An IC contains five values: the, the most recent target class of the, the address of the most recently looked-up for the, a hotness counter, and a trip counter.... literals s trailer... class address hotness counter trip counter inline cache Fig. 3. A former literal slot referencing an IC. The interpreter increases the hotness counter each time it executes the corresponding message. It then also checks whether the target class is the same as it was when the was executed the last time. If so, the stored address is used to retrieve the implementation to be executed. If the receiver class check fails, the trip counter is increased, and the correct class and implementation are looked up and stored.

6 If such a site causes actual lookups too often, its IC reference can be replaced with a PIC reference (cf.fig.4). A PIC is organized much like an IC : it also carries the in question and type feedback information. The notable difference is that a PIC carries up to 8 triples of receiver class, address, and hotness counter. (CompiledMethod instance literal slot) class address hotness counter class hotness address counter... polymorphic inline cache Fig. 4. A PIC referenced from a CompiledMethod instance. The interpreter, when executing the corresponding, iterates over the PIC and checks for the correct receiver class. Once it finds one already stored, the respective stored is executed and the pertaining hotness counter is increased. If no matching receiver class is found, lookup proceeds as usual and the result is stored in a free slot of the PIC if available. It is not necessary to store a hotness counter alongside with each PIC entry, but future optimizations can benefit from this information (see below). 4 Summary and Future Optimizations In the previous sections, we have discussed caching optimization mechanisms for interpreters. In our opinion, global caches are, although helpful with regard to performance, not fully supportive of dynamic optimizations possible in interpreters. For that we propose the introduction of PICs based on local type feedback. The locality of type feedback information is a feature of PICs that can be exploited beyond performance improvements in the VM. Type feedback information made available at the image level facilitates optimizations above the abstraction barrier imposed by the Squeak VM. The AOStA (Adaptively Optimizing Smalltalk Architecture) project [10] relies on type feedback from the VM to dynamically and adaptively optimize Smalltalk s in the image using manipulation. An example of such an optimization is inlining: based on type feedback information and hotness counter data, s frequently invoked from a given site can be inlined directly at the image level, without the need to create stack frames and context s. Originally, AOStA has been conceived for the VisualWorks VM [3]. The VisualWorks JIT compiler generates PICs at sites. A system like AOStA can be beneficial also to purely interpreted systems like Squeak Smalltalk if the underlying interpreter supports type feedback using PICs, as proposed in this paper.

7 Acknowledgments. We gratefully acknowledge the financial support of the Swiss National Science Foundation for the project Analyzing, capturing and taming software change (SNF Project No , Oct Sept. 2008). References 1. M. Arnold, S. J. Fink, D. Grove, M. Hind, and P. F. Sweeney. A Survey of Adaptive Optimization in Virtual Machines. Proceedings of the IEEE, 93(2), M. Berndl, B. Vitale, M. Zaleski, and A. D. Brown. Context Threading: A Flexible and Efficient Dispatch Technique for Virtual Machine Interpreters. In CGO 05: Proceedings of the international symposium on Code generation and optimization, pages IEEE Computer Society, Cincom Home Page L. P. Deutsch and A. M. Schiffman. Efficient Implementation of the Smalltalk-80 System. In POPL 84: Proceedings of the 11th ACM SIGACT-SIGPLAN symposium on Principles of programming languages, pages ACM Press, U. Hölzle, C. Chambers, and D. Ungar. Optimizing Dynamically-Typed Object- Oriented Languages With Polymorphic Inline Caches. In ECOOP 91: Proceedings of the European Conference on Object-Oriented Programming, pages Springer-Verlag, U. Hölzle and D. Ungar. Optimizing Dynamically-Dispatched Calls With Run- Time Type Feedback. In PLDI 94: Proceedings of the ACM SIGPLAN 1994 conference on Programming language design and implementation, pages ACM Press, U. Hölzle and D. Ungar. Do Object-Oriented Languages Need Special Hardware Support? In ECOOP 95: Proceedings of the 9th European Conference on Object- Oriented Programming, pages Springer-Verlag, D. Ingalls, T. Kaehler, J. Maloney, S. Wallace, and A. Kay. Back to the Future: the Story of Squeak, a Practical Smalltalk Written in Itself. In Proc. OOPSLA 1997, pages ACM Press, P. Klint. Interpretation Techniques. Software Practice and Experience, 11(9): , E. Miranda. A Sketch for an Adaptive Optimizer for Smalltalk written in Smalltalk. unpublished, I. Piumarta and F. Riccardi. Optimizing Direct Threaded Code by Selective Inlining. In PLDI 98: Proceedings of the ACM SIGPLAN 1998 conference on Programming language design and implementation, pages ACM Press, Squeak Home Page Squeak Virtual Machine Home Page Strongtalk Home Page.