1. Introduction In this paper we quantitatively evaluate the memory In this paper we evaluate the memory system behavior of system behavior of two different implementations of the two distinctly different implementations of the UNIX UNIX operating system. One system, DEC's Ultrix, has a operating system: DEC's Ultrix, a monolithic system, and monolithic structure. The other, Mach 3.0 with CMU's Mach 3.0 with CMU's UNIX server, a microkernel-based UNIX server [1, 21], has a microkernel structure. Both system. In our evaluation we use combined system and systems are derived from 4.2 BSD UNIX and share a user memory reference traces of thirteen industry-standard nearly identical application programming interface, as workloads. We show that the microkernel-based system well as large amounts of code. We explore these two executes substantially more non-idle system instructions systems within the framework of seven popular assertions for an equivalent workload than the monolithic system. ab...

This white paper describes Scout, a new operating system being designed for systems connected to the National Information Infrastructure (NII). Scout provides a communication-oriented software architecture for building operating system code that is specialized for the different systems that we expect to be available on the NII. It includes an explicit path abstraction that both facilitates effective resource management and permits optimizations of the critical path that I/O data follows. These path-enabled optimizations, along with the application of advanced compiler techniques, result in a system that has both predictable and scalable performance. June 17, 1994 Department of Computer Science The University of Arizona Tucson, AZ 1 Introduction As the National Information Infrastructure (NII) evolves, and digital computer networks become ubiquitous, communication will play an increasingly important role in computer systems. In fact, a recent report on the NII rejects the term "compu...

In modern systems, developers are often unable to modify the underlying operating system. To build services in such an environment, we advocate the use of gray-box techniques. When treating

We have modified Mach 3.0 to treat cross-domain remote procedure call (RPC) as a single entity, instead of a sequence of message passing operations. With RPC thus elevated, we improved the transfer of control during RPC by changing the thread model. Like most operating systems, Mach views threads as statically associated with a single task, with two threads involved in an RPC. An alternate model is that of migrating threads, in which, during RPC, a single thread abstraction moves between tasks with the logical flow of control, and "server" code is passively executed. We have compatibly replaced Mach's static threads with migrating threads, in an attempt to isolate this aspect of operating system design and implementation. The key element of our design is a decoupling of the thread abstraction into the execution context and the schedulable thread of control, consisting of a chain of contexts. A key element of our implementation is that threads are now "based" in the kernel, and temporar...

Modern commodity operating systems are large and complex systems developed over many years by large teams of programmers, containing hundreds of thousands of lines of code. Consequently, it is extremely difficult to add significant new functionality to these systems. In response to this problem, a number of recent research projects have explored novel operating system architectures to support untrusted extensions, including SPIN, VINO, Exokernel, and Fluke. Unfortunately, these architectures require substantialimplementation effort and are not generally available in commodity systems. In contrast, by leveraging the technique of interposition, we have designed and implemented a prototype extension system called SLIC which requires only trivial operating system

Abstract not found

This paper addresses the issues faced when constructing an operating system and its kernel with object-oriented technology. We first propose object/metaobject separation, a means of constructing an object-oriented operating system and its kernel. This method divides the implementing system facilities and applications into two types: objects and metaobjects. This paper presents the concept of object/metaobject separation and discusses why object/metaobject separation is required in terms of limitations in the micro-kernel and object-oriented technologies. We also discuss an example of using object/metaobject separation as implemented in Apertos. This paper then proposes mechanisms which efficiently implement object/metaobject separation. These are characterized by meta-level context management, and are implemented in the Apertos operating system. Meta-level context management is designed to reduce the overhead of control transfer between an object and its metaspace. Here, metaobjects re...

This paper argues that efficient, incremental customization of OS services can be achieved using a twofold strategy: an object-oriented architecture that relies on composition to facilitate code reuse and customization; and, an OS structure that places a minimal set of trusted functions into the kernel, with all remaining services collocated with application code in user-level protection domains. 1 Introduction Historically, operating systems have followed the abstract machine model, providing a black box abstraction of services available to applications. It has been the task of the OS implementor to provide a generic implementation of these services, one that offers good performance to a wide range of application programs. Many---if not most---applications are served well with a generic implementation of a simple, high-level abstraction. However, sophisticated applications often cannot make due with the performance of a generic service offered by the OS. For example, a generic file s...

In RPC-based communication, it is useful to distinguish the RPC interface, which is the "network contract" between the client and the server, from the presentation, which is the "programmer's contract" between the RPC stubs and the code that calls or is called by them. Presentation is usually a fixed function of the RPC interface, but some RPC systems, such as DCE and Concert, support the notion of a flexible presentation or endpoint modifier, allowing controlled modification of the behavior of the stubs on each side without affecting the contract between the client and the server. Up until now, the primary motivation for flexible presentation has been for programmer convenience and improved interoperability. However, we have found flexible presentation also to be useful for optimization of RPC, and in many cases necessary to achieving maximal performance without throwing out the RPC system and resorting to hand-coded stubs. In this paper we provide examples demonstrating this point fo...

Applications often require functionality that is implemented in the kernel, but is not directly available to the user level. While extensible operating systems allow kernel functionality to be augmented, we believe that the emphasis on extensibility is misplaced. Applications should be able to reuse kernel code directly and the emphasis should be placed on designing a kernel with that reuse in mind. The advantage of structuring the kernel as a set of reusable, extensible tools is that applications can avoid re-implementing functionality that is already present in the kernel. This will lead to smaller applications, fewer lines of total code, and a more unified computing environment that will be easier to maintain and perform better. 1 Introduction Many applications share functionality with the operating system kernel. For example, databases and file systems manage persistent data, arbitrate shared access, and sometimes implement transactions. File systems and many applications (e.g. te...