Reflective Object Management in the Muse Operating System

Yasuhiko Yokote, Atsushi Mitsuzawa?, Nobuhisa Fujinami, and Mario Tokoroy

Sony Computer Science Laboratory Inc.

Takanawa Muse Building,

3-14-13 Higashi-gotanda, Shinagawa-ku, Tokyo 141 JAPAN

Abstract

This paper presents reflective object management as s set of facilities for handling objects with various properties such as grain-size and lifespan efficiently and naturally. The facilities are classes, variablelength identifiers, memory management, and efficient communication between objects. A class hides details of the implementation of an object such as language and hardware dependency. An identifier is a variable whose length depends on its naming context. There are two or more naming contexts in the system which compose a hierarchical structure. Each naming context guarantees the uniqueness of identifiers it contains. Address spaces are divided into equal sized fragments or slots, and several objects may reside in one address space. This reduces the context switching overhead caused by communication. By tracing communication paths, execution of extra paths can be avoided by replacing them with local procedure calls. These facilities are based on the Muse object architecture and implemented on the Muse operating system. Reflective object management can define objects in such a way that there is no distinction between objects supported by operating systems and objects supported by programming languages in a multi-lingual environment. We also show our preliminary evaluation of the implementation.

1 Introduction

New hardware and software technologies increase the expectations and demands of computer users. With respect to operating systems and the applications they support, there are several specific expectations that future systems should meet. The first concerns the scale of the system. Accurately predicting the number of entities | workstations, portable and mobile computers, persistent objects, devices, activities, address spaces, etc. | to be manipulated at system configuration time is impossible. Therefore, the number of entities that a system can manage should not be limited. Second is distribution. As networks becomes even faster and internationalization continues, the need for geographically distributed systems will increase. The distance between entities is inherently important in such systems. Third is openendedness of the system. It should be relatively easy

?Department of Computer Science, Keio University. yalso with Keio University.

to create new operating system functions, integrate new services, and add new processors. Since such a system makes no distinction between the levels of protection for systems and users, we can easily use well-designed system objects as building blocks.

In systems providing the above features, objects are constantly emerging, vanishing, evolving, and being replaced. These objects have various properties dependent on diverse programming languages and applications. There are objects which consume large amount of memory to store continuous multimedia data such as video and audio, even in a programming language supporting fine-grained objects. There are objects which are created and then deleted quickly: an object such as a temporary file to store an intermediate result of compilation has similarly short lifetime. Also, while location and persistence tranceparency are useful for application objects, objects which implement database systems need their location such as a node name and a storage device name. Objects are protected from each other, and there are different kinds of relationships between them such as the object/class relationship, the precedence relationship, the uses" relationship, etc. These are useful for services such as pre-fetching upon object migration.

We propose reflective object management as a set of facilities for handling objects with the above various properties. This paper focuses on objects with various granularity and lifespan. In reflective object management, there is no distinction between objects supported by operating systems and objects supported by programming languages in a multilingual environment. The facilities we propose are composed of three subsystems: class systems, memory management, and communication management. These are based on the Muse object architecture [Yokote et al. 91] and implemented in the Muse operating system [Yokote et al. 89a] [Yokote et al. 89b].

Class systems accommodate language and hardware heterogeneity: a class hides the implementation of an object. Each class acts as a template for the objects; a class contains: the (initial) size of the object, method names available outside of the object, and names of the superclasses (if any). A class also includes language dependent information such as text codes, initial data of the objects, and their relocation information (if any).

Communication management provides variablelength identifiers and dynamic optimization of com-