The principal tasks of an operating system are to manage the resources of the system, maintain the permanent data of the system and to provide an efficient environment for the execution of user programs. In conventional operating systems these tasks are centred around the file system as the repository of permanent data and virtual memory as the execution environment. Persistent systems offer an alternative view in which the lifetime of data is separated from the access mechanism. In a persistent system all data, regardless of its lifetime, is created and manipulated in a uniform manner. When persistence is included as the basic abstraction of an operating system, many of the inadequacies of existing operating systems are eliminated and the tasks of an application developer are greatly simplified. This results in major improvements both in terms of program development time and execution efficiency. Grasshopper, a persistent operating system being developed by the authors, pr...

The PerDiS (Persistent Distributed Store) project addresses the issue of providing support for distributed collaborative engineering applications. We describe the design and implementation of the PerDiS platform, and its support for such applications. Collaborative engineering raises system issues related to the sharing of large volumes of ne-grain, complex objects across wide-area networks and administrative boundaries. PerDiS manages all these aspects in a well dened, integrated, and automatic way. Distributed application programming is simplied because it uses the same memory abstraction as in the centralized case. Porting an existing centralized program written in C or C++ is usually a matter of a few, well-isolated changes. We present some performance results from a proof-of-concept platform that runs a number of small, but real, distributed applications on Unix ? This work was supported by Esprit under the PerDiS project (n o 22533), http://www.perdis.esprit.ec...

A key decision in the design of an operating system is which facilities to provide for the management and composition of the address space. A wide spectrum of schemes exist, ranging from the private process address spaces of Unix through to the recently revived single address space approach. This paper proposes a new model which provides a unified and generalised approach to address space management. The model presents a single abstraction of address spaces which are orthogonal to processes and may be composed in arbitrary ways. The power of the model is demonstrated by case studies which show how shared libraries, a Unix system and a single address space system may be implemented. 1. Introduction The structure and facilities provided for the manipulation of the address space constitute a fundamental element in the design of an operating system. The approach taken effectively dictates the computational model for programs executing on the system and can limit the scope of the sharing ...

Rapid advances in processing power, memory and disk capacity, and network bandwidth are leading us to an era in which we will have access to virtually unlimited resources at our fingertips. We are moving away from a hardware-centric view of computing to a more service-oriented perspective, i.e. users simply want to accomplish their tasks on their data, and they do not care about the machine specifics and management details. The future computing infrastructure will provide ubiquitous access to active computations floating on a sea of globally distributed resources. When executing in this context, our computing environments must become hassle-free and much easier to manage. This thesis describes two core concepts to help enable this transition. First, we

Persistent stores have been implemented using a variety of storage technologies including shadow paging, log-based and log-structured approaches. Here we compare these approaches and advocate the use of log-structuring. The advantages of such a technique include efficient support for large (64 bit) address spaces, scalability and fast snapshot processing. We describe the architecture of a new log-structured persistent store and how it has been used to support resilient persistent processes in the context of the Grasshopper operating system. This store is based on the use of a log server which provides clients with private logical logs. Keywords persistent stores, log-structured stores, recoverable virtual memory. 1 Introduction The concept of persistence may be defined as the attribute of data which specifies its period of existence. Stemming from this simple definition, a wide range of systems supporting various forms of persistence have emerged. In systems that support orthogonal ...

Caching and persistence support efficient, convenient and transparent distributed data sharing. The most natural model of persistence is persistence by reachability, managed automatically by a garbage collector (GC). We propose a very general model of such a system (based on distributed shared memory) and a scalable, asynchronous distributed GC algorithm. Within this model, we show sufficient and widely applicable correctness conditions for the interactions between applications, store, memory, coherence, and GC.

In this paper, the authors share their experiences gathered during the design and implementation of the CORBA Persistent Object Service. There are two problems related to a design and implementation of the Persistence Service: first, OMG intentionally leaves the functionality core of the Persistence Service unspecified; second, OMG encourages reuse of other Object Services without being specific enough in this respect. The paper identifies the key design issues implied both by the intentional lack of OMG specification and the limits of the implementation environment characteristics. At the same time, the paper discusses the benefits and drawbacks of reusing other Object Services, particularly the Relationship and Externalization Services, to support the Persistence Service.

The Mungi single address space operating system provides a protected procedure call mechanism named protection domain extension (PDX). The PDX call executes in a protection domain which is the union of (a subset of) the caller’s domain, and a fixed domain associated with the procedure. On return, the caller’s original protection domain is re-established. Extensive caching of validation data allows amortisation of setup costs over a possibly large number of invocations. The PDX mechanism forms the basis for object support in Mungi, particularly encapsulation. It is also used for accessing devices, and to implement userlevel page fault handlers and other services.

Orthogonal persistence opens up the possibility for a number of applications. We present an approach for easily enabling transparent orthogonal persistence, basically on top of a modern -kernel. Not only are all data objects made persistent. Threads and tasks are also treated as normal data objects, making the threads and tasks persistent between system restarts. As such, the system is fault surviving. Persistence is achieved by the means of a transparent checkpoint server running in user-level. The checkpoint server takes regular snapshots of all user-level memory in the system, and also of the thread control blocks inside the kernel. The execution of the checkpointing itself is completely transparent to the -kernel, and only a few recovery mechanisms need to be implemented inside the kernel in order to support checkpointing. During system recovery (after a crash or a controlled shutdown), the consistency of threads is assured by the fact that all their user-level state (user memory) and kernel-level state (thread control blocks) will reside in stable storage. All other kernel state in the system can be reconstructed either upon initial recovery, or by standard page fault mechanisms during runtime.

Over the last 15 years a number of persistent language systems have been produced whose implementation relies on the persistence mechanisms provided by an underlying operating system. We have produced an operating system called Grasshopper expressly designed to support orthogonally persistent systems. In this paper we demonstrate how the mechanisms provided by Grasshopper may be used to implement a persistent version of the language Java.