Pointer swizzling is the conversion of database objects between an external form (object identifiers) and an internal form (direct memory pointers). Swizzling is used in some object-oriented databases, persistent object stores, and persistent and database programming language implementations to speed manipulation of memory resident data. Here we describe a simplifying model of application behavior, revealing those aspects where swizzling is most relevant in both benefits and costs. The model has a number of parameters, whichwehavemeasured for a particular instance of the Mneme persistent object store, varying the swizzling technique used. The results confirm most of the intuitive, qualitative tradeoffs, with the quantitative data showing that some performance differences between schemes are smaller than might be expected. However, there are some interesting effects that run counter to naive intuition, most of which we explain using deeper analysis of the algorithms and data struc...

A key mechanism of a persistent programming language is its ability to detect and handle references to non-resident objects. Ideally, this mechanism should be hidden from the programmer, allowing the transparent manipulation of all data regardless of its potential lifetime. We term such a mechanism object faulting, in a deliberate analogy with page faulting in virtual memory systems. This paper presents a number of mechanisms for detecting and handling references to persistent objects, and evaluates their relative performance within an implementation of Persistent Smalltalk.

LIGHTWEIGHT SUPPORT FOR FINE-GRAINED PERSISTENCE ON STOCK HARDWARE FEBRUARY 1995 ANTONY LLOYD HOSKING B.Sc., UNIVERSITY OF ADELAIDE M.Sc., UNIVERSITY OF WAIKATO Ph.D., UNIVERSITY OF MASSACHUSETTS AMHERST Directed by: Professor J. Eliot B. Moss Persistent programming languages combine the features of database systems and programming languages to allow the seamless manipulation of both short- and long-term data, thus relieving programmers of the burden of distinguishing between data that is transient (temporarily allocated in main memory) or persistent (residing permanently on disk). Secondary storage concerns, including the representation and management of persistent data, are directly handled by the programming language implementation, rather than the programmer. Moreover, unlike traditional database systems, persistent programming languages extend to persistent data all the data structuring features supported by the language, not just those imposed by the underlying database system. P...

Reachability-based persistence imposes new requirements for main memory management in general, and garbage collection in particular. After a brief introduction to the characteristics and requirements of reachability-based persistence, we present the design of a run-time storage manager for Persistent Smalltalk and Persistent Modula-3, which allows the reclamation of storage from both temporary objects and buffered persistent objects.

same services in different ways). This is in contrast to the monolithic approach in which components are tightly-connected and interdependent. In particular, when the components interconnect in a layered fashion, the higher the layer is, the more semantics it has about the domain. In programming environments, the highest layer is the human programmer, the middle layer is the environment itself, with limited knowledge, and the lowest layers that support the environment have minimal semantic knowledge about the domain. The various layers should have great flexibility in implementing their functionality. This is the intuition for the first model presented in chapter 2 and its implementation in MARVEL, presented in 6. The second approach is to exploit the object-oriented paradigm in distribution, i.e., impose object-oriented decomposition on the participating nodes in a distributed system as a coarser 1 layer of abstraction on top of the data itself. This

Persistent systems manage main memory as a cache for efficient access to frequently-accessed persistent data. Good cache management requires some knowledge of the semantics of the applications running against it. We are attacking the performance problems of persistence for Java through analysis, profiling, and optimisation of Java classes and methods executing in an orthogonally persistent setting. Knowledge of application behaviour is derived through analysis and profiling, and applied by both a static bytecode transformer and the run-time system to optimise the actions of Java programs as they execute against persistent storage. Our prototype will unify distinct persistence optimisations within a single optimisation framework, deriving its power from treatment of the entire persistent application, consisting of both program code and data stored in the database, for wholeapplication analysis, profiling and optimisation. Keywords: persistence, Java, bytecode, program analysis, dynami...

INTRODUCTION A persistent system #Atkinson et al. 1982; Atkinson et al. 1983; Atkinson et al. 1983; Atkinson and Buneman 1987# maintains data independently of the transitory programs that create and manipulate that data---data may outlive their creators, and be manipulated by yet other programs. To achieve this, persistent systems provide an abstraction of persistent storage, which programmers view as a stable This work has been supported by the National Science Foundation under grants CCR-9211272, CCR-8658074 and DCR-8500332, and by the following companies and corporations: Sun Microsystems, Digital Equipment, Apple Computer, GTE Laboratories, Eastman Kodak, General Electric, ParcPlace Systems, Xerox, and Tektronix. Name: Antony L. Hosking A#liation: Purdue University Address: Department of Computer Sciences, Purdue University,West Lafayette, IN 47907-1398, hosking@cs.purdue.edu Name: J. Eliot B. Moss A#liation: University of Massachuset

We explore the ramifications of object residency assumptions and their impact on residency checking for several subroutine dispatch scenarios: procedural, static object-oriented, and dynamic (virtual) object-oriented. We obtain dynamic counts of the residency checks necessary for execution of several benchmark persistent programs under each of these scenarios. The results reveal that significant reductions in the number of residency checks can be achieved through application of residency rules derived from the dispatch scenario under which a program executes, as well as additional constraints specific to the language in which it is implemented. Keywords: residency checks, optimization, object-orientation, static/dynamic dispatch 1 Introduction Persistent programming languages view permanent storage as a stable extension of volatile memory, in which objects may be dynamically allocated, but which persists from one invocation to the next. A persistent programming language and object st...

We describe how reachability-based orthogonal persistence can be supported even in uncooperative implementations of languages such as C++ and Modula-3, 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 OO7 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. 1 Introduction Incorporating orthogonal persistence [11] ...

In order to support long-lived distributed objects, object activation is required. Activation allows an object to alternate between periods of activity, where the object implementation executes in a process; and periods of dormancy, where the object is on disk and utilizes no system resources. We describe an activation protocol for distributed object systems. The protocol features overall simplicity as well as applicability to several different activation models. We use the Modula-3 network object system as a base for our implementation; while we make no changes to the underlying network object subsystem, we suggest a minor modification that could be made to the marshalling of network objects to assist in lazy activation, our preferred activation model. 1 Introduction Distributed object systems are designed to support long-lived persistent objects. Given that these systems will be made up of many thousands (perhaps millions) of such objects, it would be unreasonable for object implem...