No abstract

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 aifferent kinds of remote objects. For any given kind of object, this architecture lets direrent 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. IntroductionCaching of file and naming information has been used in operating systems for many years. It was originally used in timesharing systems to avoid disk operations (e.g. the UNIX@ operating system 111) and was later used in distributed systems to reduce network accesses and server loading (e.g. the Andrew [23 and Sprite [3] file systems). Measurements of distributed systems [2,3] have shown caching to be very effective in improving performance. In fact, in many cases caching can allow access to remote information to be as efficient as access to local information.This paper describes a general architecture for caching in Spring, a distributed operating system that is structured around the notion of objects. A Spring object is an abstraction that contains state and provides a set of operations to manipulate that state. Spring objects are implemented by domains which consist of an address space and a collection of threads; a domain in Spring is similar to a process on other systems such as the UNIX operating system. Objects can be freely passed between domains. Object invocations go to the implementor of the object which can be the same domain that is invoking the operation, another domain on the same machine, or a domain on a different machine.In Spring we use caching to improve the performance of operations on remotely implemented objects. Our goal is to make operations on remotely implemented objects as efficient as operations on locally implemented objects. In order to implement caching on Spring, we developed an architecture for caching that has several interesting features. First, the architecture is designed to be used to implement caching with coherency for many types of objects. This is important because new types of objects can be introduced into Spring at any time and we want to make the benefits of caching easily available to implementations of these new objects. This is a different approach from that taken in systems such as the UNIX and Sprite operating systems where the number of cacheable objects is fixed and no general caching architecture is available.The second interesting feature of the Spring caching architecture is that caching is performed by a separate cacher domain. This is a different approach than...

Two specific problems faced in large distributed systems are (1) evolving and managing different versions of an interface while minimizing the impact on existing clients, and (2) supporting the addition of auxiliary interfaces that are orthogonal to the main interface of an abstraction.In the context of the Spring distributed system, we addressed both problems using an object-oriented interface definition language. Different versions of an interface are represented as different types with an inheritance relationship that minimizes the impact on existing clients and allows easy management of versions.We distinguish between fundamental and auxiliary properties each of which are defined as separate types. Rather than use simple root inheritance, we use a combination of root and leaf inheritance. This provides flexibility in supporting auxiliary properties and allows us to add new auxiliary properties as the system evolves without forcing the system to be recompiled.The solutions have been tested and refined through their use in the Spring system.

No abstract

This publication was reproduced from the besr available camera-ready copy submitted by the subcontractor and received no editorial review at NREL. NOTICE This report was prepared as an account of work sponsored by an agency oi the United Stztes government. Neither the United States government nor any agency thereof, nor any of their employees. makes any warranty, express or implied, or assumes any legal liability or responsibility for the accurzcy, completeness. or usefulness of any inforhation, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial product, process, or service by trade name, trademark, manufacturer, or otherwise does not necessariiy constitute or imply its endorsement, recommendation, or favoring by the United States government or any agency thereof. The views and opinions of authors expressed herein do not necessariiy state or reflect those of the United States government or any agency thereof. Available to DOE and DOE contractors from: