Using Oberon's Active Objects for Language Interoperability and Compilation Patrik Reali
Total Page:16
File Type:pdf, Size:1020Kb
Using Oberon’s Active Objects for Language Interoperability and Compilation Patrik Reali Diss. ETH No. 15022 Using Oberon's Active Objects for Language Interoperability and Compilation A dissertation submitted to the SWISS FEDERAL INSTITUTE OF TECHNOLOGY ZURICH (ETH ZU¨ RICH) for the degree of Doctor of Technical Sciences presented by Patrik Rene´ Celeste Reali Dipl. Informatik-Ing. ETH born July 11, 1971 citizen of Isorno, Switzerland accepted on the recommendation of Prof. Dr. Jur¨ g Gutknecht, examiner Prof. Dr. Bertrand Meyer, co-examiner 2003 c Patrik Reali, 2003. All rights reserved i Programming in different languages is like composing pieces in different keys, particularly if you work at the keyboard. If you have learned or written pieces in many keys, each key will have its own special emotional aura. Also, certain kinds of figurations “lie in the hand” in one key but are awkward in another. So you are channeled by your choice of key. In some ways, even enharmonic keys, such as C-sharp and D-flat, are quite distinct in feeling. This shows how a notational system can play a significant role in shaping the final product. — D. Hofstadter; G¨odel, Escher, Bach: an eternal golden braid i Acknowledgments A thesis is supposed to be the work of one person. Nevertheless, this work would have not be possible without the collaboration, support, feedback, and encouragement from many persons. First of all, I would like to thank Prof. J. Gutknecht for giving me the chance to work in his group, and for his liberal supervision of the thesis. Prof. B. Meyer kindly accepted to be co-examiner and provided very competent feedbacks. I wish thank all the past and present members of the language and run-time research group, which created such an interesting and challenging environment, in particular Pieter Muller, who shared the same office with me for more than four years, and for introducing me to the secrets of system construction and of south african culture. Many thanks go also to A. Disteli, B. Egger, A. Fischer, T. Frey, P. Kramer, E. Oswald, K. Skoupy, E. Zeller, and E. Zueff. The Institute for Computer Systems at ETH provided a very lively frame to any kind of discus- sions and activities, ranging from technical topics to wine tasting. Life at ETH would have been dull without H. Domjan, R. Karrer, C. Kurmann, C. von Praun, E. Ruiz, H. Sommer, M. Taufer, and all the past and present members of the institute. Never miss a coffee break or an Assistentenabend for any reason! The student assignments of G. Banfi, R. Laich, and R. Morelli has been relevant for this thesis, and greatly helped me. Some external collaborations need also to be mentionned: P. Januschke for the interesting and productive discussions about the design and implementation of OberonX; M. van Hacken for fruit- ful collaboration in project Hostess; A. Freed and C. Langreiter for the constant encouragement. I’m deeply indebted to S. Brawer and A. Fischer for reading early drafts of this thesis and pointing out many errors or inconsistencies. Last but not least, I would like to thank my parents Annie and Carlo, and my wife Andrea, for their support and the great display of patience (or forced unto them). iii Table of Contents Acknowledgments iii Table of Contents v Abstract vii Kurzfassung ix 1 Introduction 1 1.1 Motivation . 2 1.2 This Thesis . 4 1.3 Overview . 5 2 Conceptual Framework 7 2.1 Layered system . 7 2.2 Components and Interoperability . 11 2.3 The Aos Approach . 16 2.4 Related Work . 19 3 Interoperability 25 3.1 Introduction . 25 3.2 Type Mapping . 27 3.3 Object Model Flavors . 32 3.4 Mappings and Conversions . 36 3.5 Examples . 45 3.6 Wrap-up . 47 3.7 The Jaos Approach . 50 4 Active Objects in Practice: the Active Oberon Language 53 4.1 Introduction . 53 4.2 Object Oriented Extensions . 58 4.3 Concurrency Support . 62 v vi Table of Contents 4.4 Other Language Extensions . 64 4.5 Interoperability Additions . 66 5 Case Study: The Active Oberon Compiler 67 5.1 The Compiler Framework . 67 5.2 Metadata Repository . 68 5.3 Scope Concurrent Parser . 73 5.4 Back-End Component . 76 5.5 Plug-Ins . 84 5.6 Interoperability with Java . 91 5.7 Compiler Testing and Maintenance . 96 6 The Aos Kernel as Language Interoperability Platform 101 6.1 Introduction . 101 6.2 Aos as Interoperability Platform . 101 6.3 Run-time Layer: API and Conventions . 103 7 Case Study: The Jaos JVM 115 7.1 Introduction . 115 7.2 Mapping Java To Aos . 120 7.3 JVM Implementation . 128 7.4 Interoperability with Oberon . 134 8 Conclusions 139 8.1 Achievements . 139 8.2 Future Directions . 140 8.3 Concluding Remarks . 142 A Active Oberon Examples 145 A.1 Synchronization Examples . 146 A.2 Active Object Examples . 152 B Critique of the Oberon Language 155 B.1 Syntax . 155 B.2 Semantic . 156 B.3 Design . 159 B.4 Other Proposals . 160 Bibliography 163 Curriculum Vitae 171 vi Abstract The modern run-time environments provide a high-level object-oriented programming model, re- flection capabilities, and a large amount of libraries. These platforms are particularly suitable to host programs written in many different languages. To let all languages reuse the common li- braries, the platform has a reflection mechanisms to access the metadata information, which can be used by the compilers to provide language interoperability in a seamless way. Writing a compiler for such platforms becomes an exercise in programming model mapping. Most of the languages rely on closely related flavors of the object-oriented model, but the mappings from one model to another are not always trivial. This thesis investigates the implementation of a language interoperability platform based on an active object-based object-oriented model. First, it analyzes the relations between the type systems of the platform and its subset used for interoperability, and the languages for the platform. Each language type system must be mappable to the platform type system, and the interoperability type system must be bidirectionally mappable to every language type system. Many languages implement a different flavor of the object-oriented model. A few simple mapping rules to transform each flavor onto another one are presented. Second, the Aos kernel implementing Active Oberon’s active object model is introduced as language interoperability platform. The language Active Oberon is presented as natural notation for the active object model. The Paco scope-parallel Active Oberon compiler is a case study that shows a non-trivial application relying on active objects. It parses each scope concurrently and solves forward references in the code with parser synchronization, instead of requiring a second parsing pass. Third, the Jaos Java Virtual Machine for Aos is presented. The jit-compiler maps the Java model to the active object model, and compiles the java byte-code using the data-layout and facili- ties provided by the kernel; the jit-compiler and the Java reflection libraries use the same metadata repository as the Active Oberon compiler: this allows both languages to interoperate seamlessly. Plugins for the metadata repository and for the kernel’s dynamic loader allow to use multiple meta- data persistency formats and multiple object-file formats at the same time. vii Kurzfassung Die modernen Laufzeitumgebungen definieren ein objektorientiertes Programmiermodel, Reflekti- onsfunktionalit¨at und umfangreiche Funktionsbibliotheken. Diese Plattformen eignen sich beson- ders gut um Programme zu unterst¨utzen, die in verschiedenen Programmiersprachen entwickelt worden sind. Um den Zugriff auf die gemeinsamen Funktionsbibliotheken zu erm¨oglichen, bietet die Plattform durch Reflektion Zugriff auf Metadaten an, damit die Compiler eine automatisierte und transparente Sprachinteroperabilit¨at gew¨ahrleisten k¨onnen. Ein Compiler f¨ur solche Platformen wird zum Programmiermodel¨ubersetzer. Obwohl die mei- sten Programmiersprachen auf Varianten des objektorientieren Modells basieren, sind die Abbil- dungen von Modelvariante zu Modelvariante sind nicht immer trivial, und oft mit semantischen Verlusten behaftet. Diese These untersucht die Implementation einer Sprachinteroperabilit¨atsplattform basierend auf aktiven Objekten. Zuerst werden die Beziehungen zwischen dem Programmiersprachtypsystems, dem Plattforms- typsystemen, und dem gemeinsamen Interoperabilit¨atstypsystem analysiert. Das Programmier- sprachtypsystem soll vollst¨andig auf das Plattformtypsystem abbildbar sein. Das Interoperabi- lit¨atstypsystem soll dazu bidirektional auf eine Untermenge des Programmiersprachtypsystem ab- bildbar sein. Es wird vorgestellt, wie die verschiedenen Varianten des objektorientierten Models aufeinander abgebildet werden k¨onnen. Zweitens wird der Aos-Kernel als Sprachinteroperabilit¨atsplattform vorgestellt. Das auf akti- ven Objekten basierte Modell und die Active Oberon Programmiersprache werden eingef¨uhrt. Der parallele Paco Compiler f¨ur Active Oberon wird als Fallstudie einer nicht trivialen Anwendung aktiver Objekte gezeigt. Paco ¨ubersetzt jeden Sichtbarkeitbereich im Quellecode nebenl¨aufig, und behandelt Symbolreferenzen, die vor der Symboldefinition auftreten, als Synchronisationsproblem, statt einen zweiten Durchlauf ¨uber den Quellcode zu verlangen. Drittens wird die Jaos Java Virtual Machine f¨ur Aos vorgestellt. Der just-in-time Compiler bil- det das Java-Model auf Oberons aktive Objekte ab. Die Abbildung verwendet so weit wie m¨oglich die Datenauslegung und Funktionalit¨at des Kernels; der jit-Compiler und die Java Reflektions- klassen bauen auf den selben Metadaten wie der Paco Compiler. Damit k¨onnen beide Sprachen transparent interoperieren. Die Plugin-basierte Architektur des Metadaten-Systems und des dy- namischen Laders erlauben die gleichzeitige Verwendung von unterschiedlichen Metadaten- und Objektfileformate. ix 1 Introduction Eine Verbesserung erfindet nur der, welcher zu fuhlen¨ weiss: dies ist nicht gut — Friedrich Nietzsche Language interoperability has been in use since the second programming language appeared, but in such a small extent, that awareness about it came only at a later stage. Every time two software components exchange information, they have to agree on a common protocol to be able to share the information: this is interoperability at work.