A first-class store is an object that captures the values of mutable objects at a particular time in a program's execution. First-class stores allow programmers to cleanly, safely, and efficiently implement "undo" and "redo" operations on mutable objects. This paper describes a generalized interface for first-class stores that allows the programmer to partition mutable data and refine the scope of store objects. We demonstrate the power of the interface by discussing three applications: version arrays, replay debugging, and nested transactions. A denotational semantics for first-class stores is given and two implementations are discussed. 1 Introduction First-class continuations provide programmers with the ability to manipulate the control of their program in many flexible ways. Operationally, we can think of capturing the current continuation as capturing the current program counter and lexical environment of a program and binding it to a variable. Similarly, invoking a continuation...

We describe the first concurrent compacting garbage collector for a persistent heap. Client threads read and write the heap in primary memory, and can independently commit or abort their write operations. When write operations are committed they are preserved in stable storage and thus survive system failures. Clients can freely access the heap during a garbage collection because a replica of the heap is created by the stable replica collector . A log is maintained to capture client write operations. This log is used to support both the transaction system and the replication-based garbage collection algorithm. Experimental data from our implementation was obtained from a transactional version of the SML/NJ compiler and modified versions of the TPC-B and OO1 database benchmarks. The pause time latency results show that the prototype implementation provides significantly better latencies than stop-and-copy collection. For small transactions, throughput is limited by the logging bandwidth...

Abstract not found

We have implemented a concurrent copying garbage collector that uses replication garbage collection. In our design, the client can continuously access the heap during garbage collection. No low-level synchronization between the client and the garbage collector is required on individual object operations. The garbage collector replicates live heap objects and periodically synchronizes with the client to obtain the client's current root set and mutation log. An experimental implementation using the Standard ML of New Jersey system on a shared-memory multiprocessor demonstrates excellent pause time performance and moderate execution time speedups. 1 Introduction As programs have become larger and more complex the use of dynamic storage allocation has increased. Increased use of object oriented and functional programming techniques further exacerbates this trend. These same trends also make automatic management of dynamic storage or garbage collection (GC) increasingly necessary. GC b...

Persistent and distributed object systems have to cope with chaos resulting of concurrent accesses and failures. This suggests the properties of atomicity, isolation and persistence of effects. This paper presents the Eos action model which is an interpretation of Moss's model. We focus on Eos's efficient support for nested isolation which upholds an adaptive granule of locking based on complex objects. In particular, we formalize nested isolation based on set and tree theory. This approach leads to an efficient implementation in the context of a distributed single-level store. First measurements showed encouraging performance of Eos that seems to outperform largely existing systems providing nested actions. Finally, we propose a simple criterion to order conflicting actions, avoiding false conflicts and therefore enhancing parallelism. 1 Introduction Persistent object systems have to deal with chaos resulting from uncontrolled sharing of data and failures. Nested transactions are adv...

We describe the design of a transaction facility for a language that supports higher-order functions. We factor transactions into four separable features: persistence, undoability, locking, and threads. Then, relying on function composition, we show how we can put them together again. Our "Tinkertoy" approach towards building transactions enables us to construct a model of concurrent, nested, multi-threaded transactions, as well as other non-traditional models where not all features of transactions are present. Key to our approach is the use of higher-order functions to make transactions first-class. Not only do we get clean composability of transactional features, but also we avoid the need to introduce special control and block-structured constructs as done in more traditional transactional systems. We implemented our design in Standard ML of New Jersey. This research is sponsored in part by the Wright Laboratory, Aeronautical Systems Center, Air Force Materiel Command, USAF, and the...

The original aim of the work that led to this dissertation was to extend an existing, purely functional language with facilities for input/output and modular programming. The language is based on an untyped -calculus, i.e., program execution is defined as program transformation according to a fixed set of reduction rules including fi-reduction. Consistently, the implementation comprises an interactive reduction system which is integrated with a syntax-oriented editor: any sub-expression or program result can be submitted for (stepwise) reduction. There is no distinguished main program, no `global' environment and no explicit static part of the language -- in particular, there is no static type system. It is therefore not clear how to add one of the known solutions for input/output or modular programming to such a programming environment. Furthermore, simply adding features to the language would lead to a complex language design with weakly integrated parts, thus losing much of the appe...

Integrating persistence into an existing programming language is a serious undertaking. Preserving the essence of the existing language, adequately supporting persistence, and maintaining efficiency require low-level support from the compiler and runtime systems. Pervasive, low-level changes were made to a Lisp compiler and runtime system to introduce persistence. The result is an efficient language whichisworthy of the name Persistent Lisp.