| A widespread practice to implement a flexible array is to consider the storage area into two parts: the used area which is already available for read/write operations and, the supply area, which is used in case of enlargement of the array. The main purpose of the supply area is to avoid as much as possible the reallocation of the whole storage area in case of enlargement. As the supply area is not used by the application, the main idea of the paper is to convey the information to the garbage collector, making it possible to avoid completely the marking of the supply area. We also present a simple method to analyze the types of objects which are stored in an array as well as the possible presence of null values within the array. This allows us to better specialize the work of the garbage collector when marking the used area, and also, by transitivity, to improve overall results for type analysis of all expressions of the source code. After introducing several abstract data types which represent the main arrays concerned by our technique (i.e. zero or variable indexing, circular arrays and hash maps), we measure its impact during the bootstrap of two compilers whose libraries are equipped with these abstract data types. We then measure, on various software products we have not written, the frequency of certain habits of manipulation of arrays, to assess the validity of our approach. |
| Reaching the best level of runtime performance from a high-level, object-oriented language is often considered challenging if not unattainable. The closed world assumption involves considering all of the source code of an application together at compile-time. That assumption makes it possible to produce an efficient code. For instance, multiple inheritance can be implemented as efficiently as single inheritance. Our compilation strategy is the result of a prolonged project, tying together several compilation techniques: call graph analysis, dead code elimination, type flow analysis, code customization, implementation of dynamic dispatch, inlining, pointer optimization, switch optimization, objects layout, etc. Merging all of these techniques into a global strategy appears to be quite problematic. Throughout the paper two real-world compilers are used as benchmarks to provide measurements for compiler-writers in order to evaluate the applicability of our approach. Type flow analysis is a fundamental aspect of our strategy to resolve method calls. We have extended type flow analysis to deal with the content of arrays, enabling us to process additional expressions and thus making it possible to obtain a true global analysis. Typically more than 90\% of method call sites are statically resolved. Our experience indicates that the closed world assumption is suitable for numerous applications. Surprisingly, even library-defined control statements from dynamic languages are perfectly processed with our strategy. The Smalltalk ifTrue:ifFalse:, whileTrue:, to:do:, etc. are, for the very first time, perfectly translated. |
| Cet article commence en présentant une technique très simple, par analyse de flots de types et ordre de remplissage imposé, permettant de prédire le {\it{}contenu} des tableaux. D'abord présentée pour les tableaux primitifs indexés à partir de 0, notre technique est ensuite étendue pour prendre en compte les autres structures de données de plus haut niveau: tableaux à indexation variable, tableaux circulaires et tables de hachage. Le résultat essentiel consiste à pouvoir faire suivre l'information de flots de types déjà collectée pour le reste du code source au travers des expressions qui manipulent des tableaux, permettant ainsi de procéder à une analyse de flots de types vraiment globale. En plus de l'amélioration de la prédiction de types utile pour la liaison dynamique et la sécurité des langages à objets, notre technique permet d'optimiser la gestion mémoire. En effet, grâce à la technique de remplissage utilisée, le ramasse-miettes (GC) n'inspecte que les zones utiles des tableaux en évitant de collecter des objets inaccessibles, référencés par les zones de réserve. Ces zones de réserve n'ont par ailleurs nullement besoin d'être initialisées avant utilisation ni nettoyées aprés usage. Les mesures présentées permettent de se rendre compte de l'impact de cette technique, aussi bien en terme de qualité de l'analyse de flots, qu'en terme de gain au niveau de la gestion mémoire durant le marquage et le balayage des tableaux. |
| This article is the conclusions of a study on the implementation of a new oriented object operating system. Indeed, starting from the analysis of our needs in communication for the development for our object mechanism, various problems appeared. In this study, we reveal that the poor flexibility in memory management is the reflection of the lack of segmentation usage. Nowadays, some processors offer advanced mecanisms of memory management through segmentation. Unfortunately, they are unusable some context as ANSI C programming. At first sight, the implementation of an operating system using such a mecanism would need prior rewriting of the stack in order to take account for memory allocation indexes. This article brings a simple and effective solution to allow processor segmentation. Moreover, this solution does not require any massive modification of the stack. |
| Nous proposons dans cet article les bases d'un modèle simple de langage orienté agents réactifs pour le langage Lisaac , langage objet à prototype compilé. Nous présentons les axiomes de bases à implémenter dans le compilateur afin d'intégrer des mécanismes agents, en s'adaptant aux spécificités d'un langage objet à prototype. Nous proposons l'intégration de mécanismes comme la gestion de messages multicast, la définition du comportement réactif de l'agent, un mécanisme de structuration de SMA, et un mécanisme d'extraction structuré de données. |
| Le marché fleurissant de l'informatique embarquée impose une réutilisabilité croissante du code existant tout en ayant de fortes contraintes matérielles. Aussi, il est nécessaire de s'adapter de plus en plus rapidement à ce matériel hétéroclite. Nous pensons que l'utilisation de langages de haut niveau, en particulier les langages objets, apporte certaines réponses à une adaptabilité rapide au sein des systèmes d'exploitation et de la couche applicative grandissante. L'évolution des langages informatiques échappe encore à la programmation système. Ici, nous dénonçons l'utilisation quasi- systématique du langage C et apportons une réelle alternative. |
| The design of the Isaac operating system comes from several years of reflexion and implementation on the need for flexibility and dynamism in future operating systems. Our goals progressively lead us towards the object-oriented concepts. Prototype-based languages appeared the most elegant manner to materialize our vision of operating system. These, coupled with a powerful language allowing changing inheritance dynamically, made it possible to create the innovating Isaac OS. |
| The design as well as the implementation of the Isaac operating system led us to set up a new programming language named Lisaac. Many features from the Lisaac language come from the Self programming language (ungar87b). Comparing to Self's skills, Lisaac integrates communications protection mechanisms as well as other tools related to operating systems' design. System interruptions support as well as drivers memory mapping have been considered in the design of Lisaac. The use of prototypes and especially dynamic inheritance, fits a flexible operating system in the making. First benchmarks of our compiled objects show that it is possible to obtain high-level prototype-based language's executables as fast as C programs are. |
| Cet article est le fruit d'une étude sur la mise en place d'un nouveau système d'exploitation entièrement en objets. En effet, à partir de l'analyse de nos besoins en matière de communication pour l'élaboration de nos mécanismes objets, différents problèmes sont apparus. Ici, nous en dénonçons un qui concerne le manque de flexibilité de la gestion mémoire par l'absence d'utilisation de la segmentation. Actuellement, certains processeurs offrent des mécanismes élaborés de gestion de la mémoire par segmentation. Mais malheureusement, ils sont inutilisables dans le contexte d'un programme C ansi par exemple. A première vue, la mise en place d'un système d'exploitation utilisant ce mécanisme nécessite de réécrire complètement le compilateur pour que ce dernier prenne en compte les indexations d'adressage mémoire. Cet article apporte une solution simple et efficace pour permettre la prise en charge de la segmentation processeur d'un programme C en mémoire. Cette solution ne nécessite aucune modification massive du compilateur. |