Michael N. Nelson

An overview of the Spring system

Spring is a highly modular, distributed, object-oriented operating system. This paper describes the goals of the Spring system and provides overviews of the Spring object model, the security model, and the naming architecture. Implementation details of the Spring microkernel, virtual memory system, file system, and UNIX emulation are supplied.<<ETX>>

Extensible file systems in spring

In this paper we describe an architecture for extensible file systems. The architecture enables the extension of file system functionality by composing (or stacking) new file systems on top of existing file systems. A file system that is stacked on top of an existing file system can access the existing file systems files via a well-defined naming interface and can share the same underlying file data in a coherent manner. We describe extending file systems in the context of the Spring operating system. Composing file systems in Spring is facilitated by basic Spring features such as its virtual memory architecture, its strongly-typed well-defined interfaces, its location-independent object invocation mechanism, and its flexible naming architecture. File systems in Spring can reside in the kernel, in user-mode, or on remote machines, and composing them can be done in a very flexible manner.

Generic support for caching and disconnected operation

Current systems use caching to provide high performance and possibly support disconnected operation. However, current solutions are type specific. With the advent of modular distributed operating systems and mobile machines there is a need to provide generic support for implementing cacheable/disconnectable services. We present an architecture that can be used to implement cacheable/disconnectable services of any type. In addition we present the implementation of this architecture on the Spring operating system. We have used this architecture for implementing file caching and are currently working on other caching implementations and providing support for disconnected operation.<<ETX>>

Virtual memory support for multiple page sizes

The advent of computers with 64-bit virtual address spaces and giga-bytes of physical memory will provide applications with many more orders of magnitude of memory than is possible today. However, to tap the potential of this new hardware, we need to re-examine how virtual memory is traditionally managed. We concentrate in this note on two aspects of virtual memory: software support for multiple page sizes, and memory management policies tuned to large amounts of physical memory. We argue for the need to examine these areas, and we identify several questions that need to be answered. In particular, we show that providing support for multiple page sizes is not as straightforward as may initially appear.<<ETX>>

A highly available scalable ITV system

As part of Time Warners interactive TV trial in Orlando, Florida, we have implemented mechanisms for the construction of highly available and scalable system services and applications. Our mechanisms rely on an underlying distributed objects architecture, similar to Spring[1]. We have extended a standard name service interface to provide selectors for choosing among service replicas and auditing to allow the automatic detection and removal of unresponsive objects from the name space. In addition, our system supports resource recovery, by letting servers detect client failures, and automated restart of failed services. Our experience has been that these mechanisms greatly simplify the development of services that are both highly available and scalable. The system was built in less than 15 months, is currently in a small number of homes, and will support the trials 4,000 users later this year.

Caching in an object oriented system

Caching is an important technique for improving performance in distributed systems. However, in general it has been performed on an ad-hoc basis, with each component of the system having to invent its own caching techniques. In the Spring operating system we provide a unified caching architecture that can be used to cache a variety of different kinds of remote objects. For any given kind of object, this architecture lets different client processes within a single machine share a single cache for accessing remote objects. This caching is performed by a separate cacher process on the machine local to client processes, the caching is transparent to the clients, and the cached information is kept coherent. This architecture has been used to implement caching for files and for naming contexts.<<ETX>>

Security in the Spring name service

Spring provides a uniform name service for an open ended collection of object types-in principle, any object, of any type, can be bound to any name. The name service implements authentication and access control to protect itself, and provides these same functions in an integrated way for the convenience of clients and the object managers that implement the various objects in the system. An object manager can delegate these functions to the name service, or implement its own policies. The name service is implemented as a collection of name servers which are generally autonomous and separate from each other and also from object managers. The architecture allows trusted and untrusted name servers and object managers to participate in providing naming and in publishing objects. Authentication is done at appropriate times to establish trust. These trust relationships are encoded in capability-like authenticated objects which are reused to avoid authentication complexity and overhead after trust is established.<<ETX>>

RISCs vs. CISCs for Prolog: a case study

This paper compares the performance of executing compiled Prolog code on two different architectures under development at U. C. Berkeley. The first is the PLM, a special-purpose CISC architecture intended as a coprocessor for a host machine. The second is SPUR, a general-purpose RISC architecture that supports tagged data. Fourteen standard benchmark programs were run on both the PLM and SPUR simulators. The compiled code for SPUR was obtained by simple macro-expansion of PLM code generated by the PLM Prolog compiler. The two implementations are compared with regard to static and dynamic program size, execution speed, and memory system performance. On average, the macrocoded SPUR implementation has a static code size 14 times larger than the PLM, executes 16 times more instructions, yet requires only 2.3 times the number of machine cycles (or has the performance of 0.43 PLMs). When memory system performance is taken into account, SPUR is equivalent to 0.29 PLMs. Optimizations of the macro-expanded code and minor architectural changes to SPUR would increase this ratio to 0.53, or 0.60 for the largest benchmarks. Thus a tagged RISC architecture can execute Prolog at least half as fast as a special-purpose CISC architecture for Prolog.