Memory Management Units (MMUs) are traditionally used by operating systems to implement disk-paged virtual memory. Some operating systems allow user programs to specify the protection level (inaccessible, readonly. read-write) of pages, and allow user programs t.o handle protection violations. bur. these mechanisms are not. always robust, efficient, or well-mat. ched to the needs of applications.

The object-oriented paradigm has gained popularity in various guises not only in programming languages, but in user interfaces, operating systems, databases, and other areas. We argue that the fundamental object-oriented concept is encapsulation, and that all object-oriented mechanisms and approaches exploit this idea to various ends. We introduce the most important of these mechanisms as they are manifested in existing object-oriented systems, and we discuss their relevance in the context of modern application development.

this paper will try to accomplish several goals (in parallel): We will argue that the actor model is an appropriate way to think about parallel computation. Since many actors may be actively sending or receiving messages at the same time, actors are inherently well suited to modelling parallel systems. We will present some specific actors which we feel should be included in the programmer's tool kit for writing parallel programs. We will show examples illustrating the use of these primitives. Futures are actors which represent the values computed by parallel processes. They can be created dynamically and disappear when they are no longer needed. Other actors may use the value of a future without concern for the feet that it was computed in parallel. Synchronization is provided by serializers, which protect actors with internal state from timing errors caused by interacting processes. We will show how these primitives have been implemented in Act 1. Act I has been implemented on a serial machine, but it simulates the kind of parallelism that would occur on a real multiprocessor machine. Discussion of the implementation will give a more concrete picture of the mechanisms involved and will also show what would be needed for an implementation on a real network of parallel processors. 12. Traditional techniques for parallelism have been inadequate

Single superclass inheritance enables simple and ecient table-driven virtual method dispatch. However, virtual method table dispatch does not handle multiple inheritance and interfaces. This complication has led to a widespread misimpression that interface method dispatch is inherently inecient. This paper argues that with proper implementation techniques, Java interfaces need not be a source of significant performance degradation. We present an efficient interface method dispatch mechanism, associating a fixed-sized interface method table (IMT) with each class that implements an interface. Interface method signatures hash to an IMT slot, with any hashing collisions handled by custom-generated conflict resolution stubs. The dispatch mechanism is efficient in both time and space. Furthermore, with static analysis and online profile data, an optimizing compiler can inline the dominant target(s) of any frequently executed interface call. Micro-benchmark results demonstrate that the expected cost of an interface method call dispatched via an IMT is comparable to the cost of a virtual method call. Experimental evaluation of a number of interface dispatch mechanisms on a suite of larger applications demonstrates that, even for applications that make only moderate use of interface methods, the choice of interface dispatching mechanism can significantly impact overall performance. Fortunately, several mechanisms provide good performance at a modest space cost.

Selector table indexing is a simple technique for method lookup in object-oriented languages, which yields good performance, is well suited to multiple inheritance and dynamic typing, but is generally disregarded for its prohibitive memory consumption. The large memory footprint is caused by keeping a table of methods, indexed by a selectorcode, for each class in the system. These tables are sparsely filled. A sparse array implementation is presented, which reduces the memory consumption by an order of magnitude, while performing retrieval in constant time. This implementation is discussed in the context of a real programming environment, and compared to selector coloring, a different memory-optimizing technique. The method is shown to be complementary to dynamic caching techniques such as inline caching. 1. Introduction Dynamic binding is both the basis of polymorphism and a source of inefficiency in objectoriented languages. The association of a message selector to its implementatio...

Virtual machines face significant performance challenges beyond those confronted by traditional static optimizers. First, portable program representations and dynamic language features, such as dynamic class loading, force the deferral of most optimizations until runtime, inducing runtime optimization overhead. Second, modular

Method look-up for dynamically typed object-oriented languages, such as SMALLTALK-80 or OBJECTIVE-C, is usually implemented by a cached inheritance search. Unfortunately, this technique is slow. A selector-indexed dispatch table implementation speeds up messages to within 10% of the speed of a statically typed language such as C++. We present a fast technique for generating compact selector-indexed dispatch tables.

Abstract. Object-oriented systems must implement message dispatch efficiently in order not to penalize the object-oriented programming style. We characterize the performance of most previously published dispatch techniques for both statically- and dynamically-typed languages with both single and multiple inheritance. Hardware organization (in particular, branch latency and superscalar instruction issue) significantly impacts dispatch performance. For example, inline caching may outperform C++-style “vtables ” on deeply pipelined processors even though it executes more instructions per dispatch. We also show that adding support for dynamic typing or multiple inheritance does not significantly impact dispatch speed for most techniques, especially on superscalar machines. Instruction space overhead (calling sequences) can exceed the space cost of data structures (dispatch tables), so that minimal table size may not imply minimal run-time space usage.

Object-oriented databases (OODBs) are believed to more naturally reflect the behavior and organization of complex application domains. The schema consists of a collection of classes, organized into hierarchies which nicely organize abstractions over the domain. Objects are created as instances of classes, encapsulating data and interpretation of data together. An important characteristic is the support for evolutionary programming, and so that existing programs may be extended with new classes without affecting other parts of the system.

ion Jean-Pierre BRIOT & Pierre COINTE LITP - Universit'e Paris-VI & Rank Xerox France 4, place Jussieu & 12, place de l'Iris 75005 Paris & 92071 La D'efense briot@litp.ibp.fr & pc@litp.ibp.fr in Proceedings of the Tenth International Joint Conference on Artificial Intelligence (IJCAI'87), Vol. 1, pages 40--43, August 1987. Abstract One of the main goals of object-oriented languages (OOLs) is to unify their universe: "every entity of the language is an object." The class concept, however, usually does not follow this wish: a class being not a real object, i.e., created from a class. The metaclass concept introduced in Smalltalk-80, attempts to give classes a first class citizenship but complicates the instantiation scheme without solving its fundamental limitations: the only partial specification of the class at the metaclass level, and the fixed number of meta-levels. Some more recent approaches, as in Loops and then CommonLoops, tend towards a better unification, but reveal the s...