O PERATING systems manage a computer's resources, maintain its permanent data, and provide an efficient environment for the execution of user programs. Users expect an operating system to provide a certain level of resilience to failure and facilities for recovering from failure with minimal interruption of computations and minimal loss of data.In conventional operating systems, these tasks are centered 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 J o h n R o s e n b e r g , A l a n D e a r l e , D a v i d H u l s e , A n d e r s L i n d s t r ö m , a n d S t e p h e n N o r r i s OPERATING SYSTEM SUPPORT FOR PERSISTANTand RECOVERABLE COMPUTATIONS Guaranteeing data recovery and consistency, the authors' experimental Grasshopper persistent operating system simplifies application development and encourages construction of integrated systems.

Since the 1980s, various groups have been constructing systems that support a concept known as orthogonal persistence. These systems support objects whose lifetime is independent of the context in which they were created. The benefits of such systems include greater run-time efficiency, strong semantic guarantees about the existence of data and its type, early error checking, and lower construction costs. However, the implementation of persistent systems has been hindered by the lack of support provided by the operating system. This paper examines the implementation of persistent systems on traditional operating systems and on operating systems that directly support persistence, and looks at current attempts to provide flexible architectures that permit persistence to be provided efficiently above the operating system. CopyrightConventional operating systems ¶ expect to support processes that access only short-lived data held in directly addressable physical or virtual memory. Long-lived data is held in secondary storage and cannot be directly addressed. This has led to the establishment of separate operating system APIs for each class of data creating a dichotomy between long-and short-lived data. For example, in Unix one set of system calls is responsible for the allocation of virtual memory (e.g. break) and others that deal with files (e.g. open, close, etc.). In contrast, systems that provide orthogonal persistence treat all data identically as persistent objects, and a single API is provided to manipulate these objects. This leads to a requirement that objects must be uniformly addressable and moved between long-and short-term storage in a manner that is transparent to the application programmer. The engineering solutions that have evolved to satisfy this requirement may be partitioned into two categories:1. Those that utilise software address translation as typified by Brown's stable store [5]. 2. Those that utilise hardware address translation.In Brown's stable store [5], which is typical of systems that utilise software address translation, two address spaces are managed: a local process address space and a persistent address space. The process address space contains objects that may be directly accessed by machine instructions. Longlived objects are stored in the persistent address space which are stored on disk. The storage system moves objects transparently from one address space to the other on demand. This requires software address translation between the local and persistent address spaces. The impact of the cost of address translation in persistent systems is not clear due to the lack of sufficient measurement. For example, Moss asserts that software address translation is more efficient than utilising hardware mechanisms as exposed by conventional operating systems [6]. This may be a condemnation of the time modern operating systems take to service a trap rather than praise for software addressing techniques. However, since the ratio of processor speed over time required to service a trap is incre...

Persistent object systems must provide some form of checkpointing to ensure that changes to persistent data are secured on non-volatile storage. When processes share or exchange modified data, mechanisms must be provided to ensure that they may be consistently checkpointed. This may be performed eagerly by synchronously checkpointing all dependent data. Alternatively, optimistic techniques may be used where processes are individually checkpointed and globally consistent states are found asynchronously. This paper examines two eager checkpointing techniques and describes a new optimistic technique. The technique is applicable in systems such as SASOS, where the notion of process and address space are decoupled.