DOCSLIB.ORG

Strongtalk: Typechecking Smalltalk in a Production Environment Abstract

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Strongtalk: Typechecking Smalltalk in a Production Environment Abstract Strongtalk: Typ echecking Smalltalk in a Pro duction Environment Gilad Bracha David Griswold [email protected] [email protected] Horizon Technologies of New York, Inc. 38 W. 32nd St., Suite 402, New York, NY 10001 Abstract tion. Understanding of e ectiveways to adapt such typing techniques to p olymorphic languages with subtyping has matured only slowly over the last TM Strongtalk is a typechecker for a downward- decade, b eginning with [Car84]. For this reason compatible Smal ltalk dialect. It is designed for among others, languages suchasLISP, Smal ltalk, large-scale production software development, and and Self that strive for extreme co de reusability incorporates a strong, modern structural type sys- through various forms of p olymorphism have tra- tem. It not only separates the notions of type and ditionally foregone the b ene ts of static typing in class, but also deals with the more dicult issue favor of the more arbitrary exibility of dynamic of separating inheritance and subtyping using the typing where all typ es are veri ed on-the- y dur- notion of inherited types [CHC90, Bru93a ] to pre- ing execution. serve encapsulation. Strongtalk integrates inherited types, metaclasses, blocks and polymorphic methods Anumb er of attempts [Suz81, BI82, GJ90] have into a highly usable, ful l-scale language. b een made to retro t a static typ e system to Smal ltalk. Most of these e orts have b een signif- icantly complicated by the extraordinary require- 1 Intro duction ment that they typ echeck large b o dies of existing Smal ltalk co de that were written without any no- It is widely accepted that a strong, static typ e sys- tion of static typ e safety in mind. tem for a programming language has imp ortant This pap er describ es a new typ echecker for b ene ts, including increased reliability, readability, Smal ltalk, called Strongtalk, that has b een designed and p otentially p erformance. However, an inad- with a quite di erent set of goals in mind. It is the equate typ e system can constrain the exibilityof b elief of the authors that the challenge of the next a language, and thus its expressiveness. decade will b e to adapt the high-pro ductivity pro- Static typing allows the typ e safety of source gramming styles of languages like Smal ltalk to the co de to b e completely determined b efore execu- very di erent rigors of very-large-scale software de- velopment, where issues such as encapsulation b e- 0 TM Strongtalk is a trademark of Horizon Technologies come more critical. of New York, Inc. App eared in pro ceedings of the ACM Conference on Accordingly, Strongtalk is an attempt to take ad- Ob ject-Oriented Programming: Systems, Languages, vantage of recenttyping advances by de ning a and Applications OOPSLA 1993. new highly-encapsulated, pro duction-oriented di- c 1993 ACM. Copied by p ermission. alect within the Smal ltalk language framework. Smal ltalk has b een chosen as the base language preserves the subtyp e relationships b etween not only b ecause of its widespread acceptance and classes de ned by the Smal ltalk metaclass hi- erarchy, and relates them to the typ es of their the availability of mature incremental develop- instances. mentenvironments, but b ecause it p ossesses sev- eral crucial features: extreme simplicity, garbage- provides facilities for dynamic typing. collection, and literal rst-class functions, in the form of blo cks. The following sections include a discussion of some 3 Design Issues of the imp ortant issues addressed by the Strongtalk design, followed by an exploration of the typ e sys- tem itself. After the typ e system has b een in- The language designer should be familiar tro duced, our exp eriences with it are presented, with many alternative features designedby followed by a section relating Strongtalk to other others, and should have excel lent judge- work. Finally,we present our conclusions. ment in choosing the best and rejecting any that are mutual ly inconsistent.... One thing he should not do is to include un- 2 Typ e System Overview tried ideas of his own. His task is consol- idation, not innovation. C.A.R. Hoare Before b eginning our discussion of the design is- sues that have shap ed Strongtalk,we present a brief list of its ma jor attributes for those who wish an Typ e systems have a deserved reputation for b e- overview. The Strongtalk typ e system ing notoriously dicult things to design and reason ab out. One of the motivations for the development has a purely structural rather than name- of Strongtalk was a feeling of dissatisfaction with based form, which provides for exible and the usability of widely available statically-typ ed complete separation of the subtyp e and sub- ob ject-oriented languages. When coming from a class lattices, while using the concept of dynamically-typ ed background, one can easily end brands [Nel91] to provide a notion of typ e up feeling that the \devil is in the details." identity. Although \checking" typ es may sound to the unini- includes parameterized typ es and classes tiated like a straightforward task, a straightforward b ounded and unb ounded quanti cation. typ e system can enormously complicate such seem- ingly mundane tasks as passing an array of strings supp orts p olymorphic messages messages to a metho d that needs a read-only arrayofany whose typ e signatures are parameterized bya typ e of ob ject. Whenever you place strict limits typ e argument, with a exible programmer- on programmers who are accustomed to none at controlled mechanism for automatically infer- all, you must b e very careful indeed that you have ring values for the typ e parameter. anticipated and provided for e ectiveways of ex- distinguishes inheritance from subtyping, pressing solutions to a great and subtle varietyof which is imp ortantforanumb er of forms common programming problems. of co de sharing, by incorp orating a tractable form of the recent notion of inherited typ es In this section we will lay the groundwork for a [Bru93a, CHC90, CCHO89], which are esp e- presentation of the Strongtalk typ e system by dis- cially useful for describing abstract data typ e cussing our ma jor design goals, and by drawing ADT hierarchies. attention to a numb er of the not-so-obvious issues classes that supp ort the proto col of another class, that can profoundly a ect the expressiveness of an without inheriting from it, and this can b e dicult ob ject-oriented typ e system. or imp ossible to do in name-based typ e systems if you do not control the source co de for that class, 3.1 Compatibility or if you are working in a single-inheritance lan- guage. A third shortcoming of all widely available statically-typ ed OO languages is extremely awk- Although Strongtalk is not designed to typ echeck ward supp ort for higher-order messages suchasit- existing Smal ltalk co de without mo di cation, nei- erators and other user-de ned control structures. ther is it intended as an incompatible language extension. Our goal has b een to eliminate the Strongtalk is designed to circumvent these sorts of risk that develop ers have traditionally had to as- awkward situations. In the rst and third situa- sume when switching to a new, untried language. tions describ ed ab ove, we take advantage of the Weachieve this through `downward compatibility', simple but p owerful combination of strongly-typ ed which means that Strongtalk co de can always b e blo cks, and p olymorphic signatures for the higher- trivially converted to Smal ltalk, but not necessarily order metho ds that take them as arguments. Ex- vice-versa. Using downward compatibility as our amples of this technique will b e presented in the b enchmark has the b ene ts of giving us some lee- exp erience section. way to de ne a very clean typ e system, while guar- To deal with the second problem describ ed ab ove, anteeing adopters of Strongtalk that at any p oint they can switch backtoSmal ltalk if they so desire, Strongtalk has a structural typ e system. In without reco ding. Other than three trivial transla- Strongtalk, an ob ject can b e passed anywhere as long as its static typ e is known to supp ort the nec- tions for manipulating uninitialized variables and essary proto col, regardless of its class. A way of ex- dynamic typ echecking, no co de transformation is plicitly de ning proto cols, and enforcing class sup- p erformed. p ort of them, is also provided. The Strongtalk prepro cessor pro duces typ esafe Smal ltalk-80 co de that preserves indentation, com- ments, and typ e annotations. 3.3 Typ e Inference Some recent languages, suchasTS [GJ90], and 3.2 Expressiveness ML [MTH90] include features to automatically in- fer variable and return typ es. Such features would Smal ltalk is an unusually exible and expressive b e convenientinatyp e system for a language like language. Anytyp e system for Smal ltalk should Smal ltalk, which lacks any sort of typ e annotations. place a high priority on preserving its essential a- However, Strongtalk do es not p erform general typ e vor. inference. Several of our design goals for Strongtalk involve There are numb er of reasons for this. In a lan- providing b etter typing solutions for situations we guage like ML, which has no concept of subtyp- have found awkward in other languages.
Load more

Recommended publications
  • Liste Von Programmiersprachen
    www.sf-ag.com Liste von Programmiersprachen A (1) A (21) AMOS BASIC (2) A# (22) AMPL (3) A+ (23) Angel Script (4) ABAP (24) ANSYS Parametric Design Language (5) Action (25) APL (6) Action Script (26) App Inventor (7) Action Oberon (27) Applied Type System (8) ACUCOBOL (28) Apple Script (9) Ada (29) Arden-Syntax (10) ADbasic (30) ARLA (11) Adenine (31) ASIC (12) Agilent VEE (32) Atlas Transformatikon Language (13) AIMMS (33) Autocoder (14) Aldor (34) Auto Hotkey (15) Alef (35) Autolt (16) Aleph (36) AutoLISP (17) ALGOL (ALGOL 60, ALGOL W, ALGOL 68) (37) Automatically Programmed Tools (APT) (18) Alice (38) Avenue (19) AML (39) awk (awk, gawk, mawk, nawk) (20) Amiga BASIC B (1) B (9) Bean Shell (2) B-0 (10) Befunge (3) BANCStar (11) Beta (Programmiersprache) (4) BASIC, siehe auch Liste der BASIC-Dialekte (12) BLISS (Programmiersprache) (5) Basic Calculator (13) Blitz Basic (6) Batch (14) Boo (7) Bash (15) Brainfuck, Branfuck2D (8) Basic Combined Programming Language (BCPL) Stichworte: Hochsprachenliste Letzte Änderung: 27.07.2016 / TS C:\Users\Goose\Downloads\Softwareentwicklung\Hochsprachenliste.doc Seite 1 von 7 www.sf-ag.com C (1) C (20) Cluster (2) C++ (21) Co-array Fortran (3) C-- (22) COBOL (4) C# (23) Cobra (5) C/AL (24) Coffee Script (6) Caml, siehe Objective CAML (25) COMAL (7) Ceylon (26) Cω (8) C for graphics (27) COMIT (9) Chef (28) Common Lisp (10) CHILL (29) Component Pascal (11) Chuck (Programmiersprache) (30) Comskee (12) CL (31) CONZEPT 16 (13) Clarion (32) CPL (14) Clean (33) CURL (15) Clipper (34) Curry (16) CLIPS (35)
    [Show full text]
  • Create Union Variables Difference Between Unions and Structures
    Union is a user-defined data type similar to a structure in C programming. How to define a union? We use union keyword to define unions. Here's an example: union car { char name[50]; int price; }; The above code defines a user define data type union car. Create union variables When a union is defined, it creates a user-define type. However, no memory is allocated. To allocate memory for a given union type and work with it, we need to create variables. Here's how we create union variables: union car { char name[50]; int price; } car1, car2, *car3; In both cases, union variables car1, car2, and a union pointer car3 of union car type are created. How to access members of a union? We use . to access normal variables of a union. To access pointer variables, we use ->operator. In the above example, price for car1 can be accessed using car1.price price for car3 can be accessed using car3->price Difference between unions and structures Let's take an example to demonstrate the difference between unions and structures: #include <stdio.h> union unionJob { //defining a union char name[32]; float salary; int workerNo; } uJob; struct structJob { char name[32]; float salary; int workerNo; } sJob; main() { printf("size of union = %d bytes", sizeof(uJob)); printf("\nsize of structure = %d bytes", sizeof(sJob)); } Output size of union = 32 size of structure = 40 Why this difference in size of union and structure variables? The size of structure variable is 40 bytes. It's because: size of name[32] is 32 bytes size of salary is 4 bytes size of workerNo is 4 bytes However, the size of union variable is 32 bytes.
    [Show full text]
  • A Metacircular Architecture for Runtime Optimisation Persistence Clément Béra
    Sista: a Metacircular Architecture for Runtime Optimisation Persistence Clément Béra To cite this version: Clément Béra. Sista: a Metacircular Architecture for Runtime Optimisation Persistence. Program- ming Languages [cs.PL]. Université de Lille 1, 2017. English. tel-01634137 HAL Id: tel-01634137 https://hal.inria.fr/tel-01634137 Submitted on 13 Nov 2017 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Universit´edes Sciences et Technologies de Lille { Lille 1 D´epartement de formation doctorale en informatique Ecole´ doctorale SPI Lille UFR IEEA Sista: a Metacircular Architecture for Runtime Optimisation Persistence THESE` pr´esent´eeet soutenue publiquement le 15 Septembre 2017 pour l'obtention du Doctorat de l'Universit´edes Sciences et Technologies de Lille (sp´ecialit´einformatique) par Cl´ement B´era Composition du jury Pr´esident: Theo D'Hondt Rapporteur : Ga¨elThomas, Laurence Tratt Examinateur : Elisa Gonzalez Boix Directeur de th`ese: St´ephaneDucasse Co-Encadreur de th`ese: Marcus Denker Laboratoire d'Informatique Fondamentale de Lille | UMR USTL/CNRS 8022 INRIA Lille - Nord Europe Numero´ d’ordre: XXXXX i Acknowledgments I would like to thank my thesis supervisors Stéphane Ducasse and Marcus Denker for allowing me to do a Ph.D at the RMoD group, as well as helping and supporting me during the three years of my Ph.D.
    [Show full text]
  • [Note] C/C++ Compiler Package for RX Family (No.55-58)
    RENESAS TOOL NEWS [Note] R20TS0649EJ0100 Rev.1.00 C/C++ Compiler Package for RX Family (No.55-58) Jan. 16, 2021 Overview When using the CC-RX Compiler package, note the following points. 1. Using rmpab, rmpaw, rmpal or memchr intrinsic functions (No.55) 2. Performing the tail call optimization (No.56) 3. Using the -ip_optimize option (No.57) 4. Using multi-dimensional array (No.58) Note: The number following the note is an identification number for the note. 1. Using rmpab, rmpaw, rmpal or memchr intrinsic functions (No.55) 1.1 Applicable products CC-RX V2.00.00 to V3.02.00 1.2 Details The execution result of a program including the intrinsic function rmpab, rmpaw, rmpal, or the standard library function memchr may not be as intended. 1.3 Conditions This problem may arise if all of the conditions from (1) to (3) are met. (1) One of the following calls is made: (1-1) rmpab or __rmpab is called. (1-2) rmpaw or __rmpaw is called. (1-3) rmpal or __rmpal is called. (1-4) memchr is called. (2) One of (1-1) to (1-3) is met, and neither -optimize=0 nor -noschedule option is specified. (1-4) is met, and both -size and -avoid_cross_boundary_prefetch (Note 1) options are specified. (3) Memory area that overlaps with the memory area (Note2) read by processing (1) is written in a single function. (This includes a case where called function processing is moved into the caller function by inline expansion.) Note 1: This is an option added in V2.07.00.
    [Show full text]
  • The Future: the Story of Squeak, a Practical Smalltalk Written in Itself
    Back to the future: the story of Squeak, a practical Smalltalk written in itself Dan Ingalls, Ted Kaehler, John Maloney, Scott Wallace, and Alan Kay [Also published in OOPSLA ’97: Proc. of the 12th ACM SIGPLAN Conference on Object-oriented Programming, 1997, pp. 318-326.] VPRI Technical Report TR-1997-001 Viewpoints Research Institute, 1209 Grand Central Avenue, Glendale, CA 91201 t: (818) 332-3001 f: (818) 244-9761 Back to the Future The Story of Squeak, A Practical Smalltalk Written in Itself by Dan Ingalls Ted Kaehler John Maloney Scott Wallace Alan Kay at Apple Computer while doing this work, now at Walt Disney Imagineering 1401 Flower Street P.O. Box 25020 Glendale, CA 91221 [email protected] Abstract Squeak is an open, highly-portable Smalltalk implementation whose virtual machine is written entirely in Smalltalk, making it easy to debug, analyze, and change. To achieve practical performance, a translator produces an equivalent C program whose performance is comparable to commercial Smalltalks. Other noteworthy aspects of Squeak include: a compact object format that typically requires only a single word of overhead per object; a simple yet efficient incremental garbage collector for 32-bit direct pointers; efficient bulk- mutation of objects; extensions of BitBlt to handle color of any depth and anti-aliased image rotation and scaling; and real-time sound and music synthesis written entirely in Smalltalk. Overview Squeak is a modern implementation of Smalltalk-80 that is available for free via the Internet, at http://www.research.apple.com/research/proj/learning_concepts/squeak/ and other sites. It includes platform-independent support for color, sound, and image processing.
    [Show full text]
  • Design and Implementation of Generics for the .NET Common Language Runtime
    Design and Implementation of Generics for the .NET Common Language Runtime Andrew Kennedy Don Syme Microsoft Research, Cambridge, U.K. fakeÒÒ¸d×ÝÑeg@ÑicÖÓ×ÓfغcÓÑ Abstract cally through an interface definition language, or IDL) that is nec- essary for language interoperation. The Microsoft .NET Common Language Runtime provides a This paper describes the design and implementation of support shared type system, intermediate language and dynamic execution for parametric polymorphism in the CLR. In its initial release, the environment for the implementation and inter-operation of multiple CLR has no support for polymorphism, an omission shared by the source languages. In this paper we extend it with direct support for JVM. Of course, it is always possible to “compile away” polymor- parametric polymorphism (also known as generics), describing the phism by translation, as has been demonstrated in a number of ex- design through examples written in an extended version of the C# tensions to Java [14, 4, 6, 13, 2, 16] that require no change to the programming language, and explaining aspects of implementation JVM, and in compilers for polymorphic languages that target the by reference to a prototype extension to the runtime. JVM or CLR (MLj [3], Haskell, Eiffel, Mercury). However, such Our design is very expressive, supporting parameterized types, systems inevitably suffer drawbacks of some kind, whether through polymorphic static, instance and virtual methods, “F-bounded” source language restrictions (disallowing primitive type instanti- type parameters, instantiation at pointer and value types, polymor- ations to enable a simple erasure-based translation, as in GJ and phic recursion, and exact run-time types.
    [Show full text]
  • Towards Gradual Typing for Generics
    Towards Gradual Typing for Generics Lintaro Ina and Atsushi Igarashi Graduate School of Informatics, Kyoto University {ina,igarashi}@kuis.kyoto-u.ac.jp Abstract. Gradual typing, proposed by Siek and Taha, is a framework to combine the benefits of static and dynamic typing. Under gradual typing, some parts of the program are type-checked at compile time, and the other parts are type-checked at run time. The main advantage of gradual typing is that a programmer can write a program rapidly without static type annotations in the beginning of development, then add type annotations as the development progresses and end up with a fully statically typed program; and all these development steps are carried out in a single language. This paper reports work in progress on the introduction of gradual typing into class-based object-oriented programming languages with generics. In previous work, we have developed a gradual typing system for Feather- weight Java and proved that statically typed parts do not go wrong. After reviewing the previous work, we discuss issues raised when generics are introduced, and sketch a formalization of our solutions. 1 Introduction Siek and Taha have coined the term “gradual typing” [1] for a linguistic sup- port of the evolution from dynamically typed code, which is suitable for rapid prototyping, to fully statically typed code, which enjoys type safety properties, in a single programming language. The main technical challenge is to ensure some safety property even for partially typed programs, in which some part is statically typed and the rest is dynamically typed. The framework of gradual typing consists of two languages: the surface lan- guage in which programmers write programs and the intermediate language into which the surface language translates.
    [Show full text]
  • Coredx DDS Type System
    CoreDX DDS Type System Designing and Using Data Types with X-Types and IDL 4 2017-01-23 Table of Contents 1Introduction........................................................................................................................1 1.1Overview....................................................................................................................2 2Type Definition..................................................................................................................2 2.1Primitive Types..........................................................................................................3 2.2Collection Types.........................................................................................................4 2.2.1Enumeration Types.............................................................................................4 2.2.1.1C Language Mapping.................................................................................5 2.2.1.2C++ Language Mapping.............................................................................6 2.2.1.3C# Language Mapping...............................................................................6 2.2.1.4Java Language Mapping.............................................................................6 2.2.2BitMask Types....................................................................................................7 2.2.2.1C Language Mapping.................................................................................8 2.2.2.2C++ Language Mapping.............................................................................8
    [Show full text]
  • Safe, Fast and Easy: Towards Scalable Scripting Languages
    Safe, Fast and Easy: Towards Scalable Scripting Languages by Pottayil Harisanker Menon A dissertation submitted to The Johns Hopkins University in conformity with the requirements for the degree of Doctor of Philosophy. Baltimore, Maryland Feb, 2017 ⃝c Pottayil Harisanker Menon 2017 All rights reserved Abstract Scripting languages are immensely popular in many domains. They are char- acterized by a number of features that make it easy to develop small applications quickly - flexible data structures, simple syntax and intuitive semantics. However they are less attractive at scale: scripting languages are harder to debug, difficult to refactor and suffers performance penalties. Many research projects have tackled the issue of safety and performance for existing scripting languages with mixed results: the considerable flexibility offered by their semantics also makes them significantly harder to analyze and optimize. Previous research from our lab has led to the design of a typed scripting language built specifically to be flexible without losing static analyzability. Inthis dissertation, we present a framework to exploit this analyzability, with the aim of producing a more efficient implementation Our approach centers around the concept of adaptive tags: specialized tags attached to values that represent how it is used in the current program. Our frame- work abstractly tracks the flow of deep structural types in the program, and thuscan ii ABSTRACT efficiently tag them at runtime. Adaptive tags allow us to tackle key issuesatthe heart of performance problems of scripting languages: the framework is capable of performing efficient dispatch in the presence of flexible structures. iii Acknowledgments At the very outset, I would like to express my gratitude and appreciation to my advisor Prof.
    [Show full text]
  • Julia's Efficient Algorithm for Subtyping Unions and Covariant
    Julia’s Efficient Algorithm for Subtyping Unions and Covariant Tuples Benjamin Chung Northeastern University, Boston, MA, USA [email protected] Francesco Zappa Nardelli Inria of Paris, Paris, France [email protected] Jan Vitek Northeastern University, Boston, MA, USA Czech Technical University in Prague, Czech Republic [email protected] Abstract The Julia programming language supports multiple dispatch and provides a rich type annotation language to specify method applicability. When multiple methods are applicable for a given call, Julia relies on subtyping between method signatures to pick the correct method to invoke. Julia’s subtyping algorithm is surprisingly complex, and determining whether it is correct remains an open question. In this paper, we focus on one piece of this problem: the interaction between union types and covariant tuples. Previous work normalized unions inside tuples to disjunctive normal form. However, this strategy has two drawbacks: complex type signatures induce space explosion, and interference between normalization and other features of Julia’s type system. In this paper, we describe the algorithm that Julia uses to compute subtyping between tuples and unions – an algorithm that is immune to space explosion and plays well with other features of the language. We prove this algorithm correct and complete against a semantic-subtyping denotational model in Coq. 2012 ACM Subject Classification Theory of computation → Type theory Keywords and phrases Type systems, Subtyping, Union types Digital Object Identifier 10.4230/LIPIcs.ECOOP.2019.24 Category Pearl Supplement Material ECOOP 2019 Artifact Evaluation approved artifact available at https://dx.doi.org/10.4230/DARTS.5.2.8 Acknowledgements The authors thank Jiahao Chen for starting us down the path of understanding Julia, and Jeff Bezanson for coming up with Julia’s subtyping algorithm.
    [Show full text]
  • Strongtalk Plan Prezentacji
    Elżbieta Bajkowska Strongtalk Plan prezentacji Czym jest Strongtalk Historia Strongtalk System typów w Strongtalk Podsumowanie Źródła Czym jest Strongtalk Składnia i semantyka Smalltalk’a-80 plus: Większa wydajność – najszybsza implementacja Smalltalk System typów – opcjonalny i przyrostowy; silny, statyczny system typów działający niezależnie od metody kompilacji (nie typowany kod Smalltalka wykonuje się równie szybko) Typowana biblioteka klas według Smalltalk Blue Book Historia Strongtalk Dwa równoległe i niezależne wątki rozwoju przyszłego systemu Strongtalk Zachodnie wybrzeże – prace grupy związanej z językiem Self nad innowacyjną maszyną wirtualną Wschodnie wybrzeże – prace nad systemem typów dla języka Smalltalk Historia Strongtalk Zachód – maszyna wirtualna Cel – poprawienie wydajności czysto obiektowego języka Self Satysfakcjonujące odśmiecanie Problem efektywnej kompilacji dla dynamicznie typowanego języka, używającego konstrukcji bloku gdzie wszystkie dane są obiektami (analogia do Smalltalk’a) - Urs Hoelzle Historia Strongtalk Wschód – system typów Dave Griswold i Gilad Bracha opracowują Strongtalk - (nazwa systemu wywodzi się od systemu typów) – konferencja OOPSLA ’93 Baza – biblioteki ParcPlace Smalltalk, nie odzwierciedlające w pełni hierarchii typów Strongtalka Zainteresowanie technologią grupy pracującej nad kompilatorem Self dla poprawienia wydajności Historia Strongtalk Połączenie technologii Animorphic Systems - Dave Griswold zaczyna współpracę z Urs’em Hoelzle (reszta grupy: Lars Bak, Gilad Bracha,
    [Show full text]
  • Type Feedback for Bytecode Interpreters Position Paper ICOOOLPS 2007
    Type Feedback for Bytecode Interpreters Position Paper ICOOOLPS 2007 Michael Haupt1, Robert Hirschfeld1, and Marcus Denker2 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, [email protected] { } Abstract. This position paper proposes the exploitation of type feed- back mechanisms, or more precisely, polymorphic inline caches, for purely interpreting implementations of object-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 bytecode interpretation itself, and caching [4, 5, 1] improves the performance of message sends—the most common operation in object-oriented software [7]. It is interesting to observe that, while threading mechanisms are used natu- rally to a varying degree in bytecode interpreter implementations, such systems usually employ only global caching to speed up dynamic method dispatch. A global cache is clearly beneficial with respect to overall performance. Still, it does not provide optimal support for polymorphic message send 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 bytecode interpreters while exhibiting only a moderate increase in memory footprint and implementation complexity.
    [Show full text]