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

Thor is a new object-oriented database management system (OODBMS), intended to be used in heterogeneous distributed systems to allow programs written in different programming languages to share objects in a convenient manner. Thor objects are persistent in spite of failures, are highly likely to be accessible whenever they are needed, and can be structured to reflect the kinds of information of interest to users. Thor combines the advantages of the object-oriented approach with those of database systems: users can store and manipulate objects that capture the semantics of their applications, and can also access objects via queries. Thor is an ongoing project, and this paper is a snapshot: we describe our first design and a partial implementation of that design. This design is primarily concerned with issues related to the implementation of an OODBMS as a distributed system. 1 INTRODUCTION Distributed systems contain different kinds of computers, and users write programs in different...

Many operating systems allow user programs to specify the protection level (inaccessible, read-only, read-write) of pages in their virtual memory address space, and to handle any protection violations that may occur. Such page-protection techniques have been exploited by several user-level algorithms for applications including generational garbage collection and persistent stores. Unfortunately, modern hardware has made efficient handling of page protection faults more difficult. Moreover, page-sized granularity may not match the natural granularity of a given application. In light of these problems, we reevaluate the usefulness of pageprotection primitives in such applications, by comparing the performance of implementations that make use of the primitives with others that do not. Our results show that for certain applications software solutions outperform solutions that rely on page-protection or other related virtual memory primitives.

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.

In this paper, different approaches are classified and evaluated for optimizing the access to main-memory resident persistent objects---techniques which are commonly referred to as "pointer swizzling ". To speed up the access along inter-object references, the persistent pointers in the form of unique object identifiers (OIDs) are transformed (swizzled) into main-memory pointers (addresses). Pointer swizzling techniques can be directed into two classes: (1) strategies that allow replacement of swizzled objects from the buffer before the end of an application program and (2) those that outrule the displacement of swizzled objects. Whereas the latter class of pointer swizzling methods has received much attention in recent literature, the first class---i.e., techniques that take "precautions" for the replacement of swizzled objects---has not yet been thoroughly investigated. Four different pointer swizzling techniques allowing object replacement were investigated and contrasted with the p...

A distributed object database stores objects persistently at servers. Applications run on client machines, fetching objects into a client-side cache of objects. If fetching and cache management are done in terms of objects, rather than fixed-size units such as pages, three problems must be solved: 1. which objects to prefetch, 2. how to translate, or swizzle, inter-object references when they are fetched from server to client, and 3. which objects to displace from the cache. This thesis reports the results of experiments to test various solutions to these problems. The experiments use the runtime system of the Thor distributed object database and benchmarks adapted from the Wisconsin OO7 benchmark suite. The thesis establishes the following points: 1. For plausible workloads involving some amount of object fetching, the prefetching policy is likely to have more impact on performance than swizzling policy or cache management policy. 2. A simple breadth-first prefetcher can have performa...

Distributed persistent object systems provide a convenient environment for applications that need to manage complex long-lived data. Since Java has no persistence model built into it, the tremendous growth in the popularity of Java has generated a lot of interest in systems that add persistence to Java. This thesis presents the design, implementation and performance evaluation of a Java Persistent Store called JPS. JPS is an efficient distributed persistent Java system built on top of the Thor object-oriented database. JPS provides

Object-oriented databases (OODBs) are believed to more naturally reflect the behavior and organization of complex application domains. The schema consists of a collection of classes, organized into hierarchies which nicely organize abstractions over the domain. Objects are created as instances of classes, encapsulating data and interpretation of data together. An important characteristic is the support for evolutionary programming, and so that existing programs may be extended with new classes without affecting other parts of the system.

Persistent programming systems are generally supported by an object store, a conceptually infinite object repository. Objects in such a repository cannot be directly accessed by user programs; to be manipulated they must be fetched from the object store into virtual memory. Thus in these systems, two different kinds of object addresses may exist: those in the object store and those in virtual memory. The action of changing object store addresses into virtual memory addresses has become known as pointer swizzling and is the subject of this paper. The paper investigates three approaches to pointer swizzling: a typical software address translation scheme, a technique for performing swizzling at page fault time and finally a new hybrid scheme which performs swizzling in two phases. The hybrid scheme supports arbitrarily large pointers and object repositories using conventional hardware. The paper concludes with a comparison of these approaches. 1

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