Operating system support for persistent and recoverable computations

Rosenberg, John; Dearle, Alan; Hulse, David; Lindström, Anders; Norris, Stephen

doi:10.1145/234215.234472

Cited by 21 publications

(10 citation statements)

References 23 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…As previously described (e.g. in [19,31]), objects in the store become dependent on each other through the activities of the processes.…”

Section: Persistent Systemsmentioning

confidence: 99%

Graph-based Optimistic Transaction Management.

Henskens¹,

Ashton²

2007

JOT

View full text Add to dashboard Cite

In this paper, we introduce and describe directed dependency graph-based transaction and concurrency control (DCC) for persistent (stable, single-level) object-based bulk data management systems. The new technique is optimistic and applicable across a wide range of store sizes, transaction sizes and multi-programming levels. It is also has potential for use in management of transactions in other contexts, for example web services.

show abstract

“…As previously described (e.g. in [19,31]), objects in the store become dependent on each other through the activities of the processes.…”

Section: Persistent Systemsmentioning

confidence: 99%

Graph-based Optimistic Transaction Management.

Henskens¹,

Ashton²

2007

JOT

View full text Add to dashboard Cite

show abstract

“…This adds considerable (avoidable) complexity to the task of making processes persistent. In addition, the coupling between the logical process and the kernel meta-data inhibits the migration of processes between machines and has been discussed elsewhere [20,21].…”

Section: Concurrent Computationmentioning

confidence: 99%

“…Grasshopper is an operating system explicitly designed to support orthogonal persistence [4,20]. To this end, it provides three abstractions, containers, loci and capabilities, all of which are inherently persistent.…”

Section: Grasshoppermentioning

confidence: 99%

See 1 more Smart Citation

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

Dearle

Hulse

2000

Softw: Pract. Exper.

Self Cite

View full text Add to dashboard Cite

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

show abstract

“…Several experimental projects have taken this approach: support for persistence is targeted explicitly in Grasshopper [29,71] and Mungi [34,371, but the rudiments are there in other experimental operating systems such as Opal [24,25], among others, Our interest here focuses on efficient support for orthogonal persistence on stock operating systems. For mostly-copying collection the heap is divided into a number of fixed-size pages, which are usually some fixed multiple of virtual memory pages.…”

Section: Performancementioning

confidence: 99%

Mostly-copying reachability-based orthogonal persistence

Hosking

Chen

1999

Proceedings of the 14th ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications

View full text Add to dashboard Cite

We describe how reachability-based orthogonal persistence can be supported even in uncooperative implementations of languages such as C++ and Modula3, and without modification to the compiler. Our scheme extends Bartlett's mostly-copying garbage collector to manage both transient objects and resident persistent objects, and to compute the reachability closure necessary for stabilization of the persistent heap. It has been implemented in our prototype of reachability-based persistence for Modula-3, yielding performance competitive with that of comparable, but non-orthogonal, persistent variants of C++. Experimental results, using the 007 object database benchmarks, reveal that the mostly-copying approach offers a straightforward path to efficient orthogonal persistence in these uncooperative environments. The results also characterize the performance of persistence implementations based on virtual memory protection primitives.

show abstract

Operating system support for persistent and recoverable computations

Cited by 21 publications

References 23 publications

Graph-based Optimistic Transaction Management.

Graph-based Optimistic Transaction Management.

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

Mostly-copying reachability-based orthogonal persistence

Contact Info

Product

Resources

About