Operating system support for persistent systems: past, present and future

Abstract

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...

Orthogonal persistence in nonvolatile memory architectures: A persistent heap design and its implementation for a Java Virtual Machine

“…There are no special cases where objects are not allowed to be long-lived or are not allowed to be transient. 3. The principle of persistence identification.…”

“…Programmers should focus on the core aspects of their applications, while the runtime environment would take care of managing the longevity of data. During the 1980s and 1990s, this concept was explored in several research initiatives, including programming languages, operating systems, and object‐oriented databases . However, the underlying implementations still had to cope with the complexity of moving data across memory and storage.…”

Ribbons

“…Its dynamic grant/deny segmentation model is potentially less secure (accidental capability leakage via bugs, manipulation) and prevents analysis of programs for automatic parallelization. Others (e.g., [15,17,30]) have similar limitations.…”

A design of the persistent operating system with non-volatile memory

“…Most existing research on the persistent operating system focus on when and how to store the main memory state with the CPU state into the permanent storage devices such as disks [3,4,5,7].…”