A future is a simple and elegant abstraction that allows concurrency to be expressed often through a relatively small rewrite of a sequential program. In the absence of side-effects, futures serve as benign annotations that mark potentially concurrent regions of code. Unfortunately, when computation relies heavily on mutation as is the case in Java, its meaning is less clear, and much of its intended simplicity lost. This paper explores the definition and implementation of safe futures for Java. One can think of safe futures as truly transparent annotations on method calls, which designate opportunities for concurrency. Serial programs can be made concurrent simply by replacing standard method calls with future invocations. Most significantly, even though some parts of the program are executed concurrently and may indeed operate on shared data, the semblance of serial execution is nonetheless preserved. Thus, program reasoning is simplified since data dependencies present in a sequential program are not violated in a version augmented with safe futures. Besides presenting a programming model and API for safe futures, we formalize the safety conditions that must be satisfied to ensure equivalence between a sequential Java program and its futureannotated counterpart. A detailed implementation study is also provided. Our implementation exploits techniques such as object versioning and task revocation to guarantee necessary safety conditions. We also present an extensive experimental evaluation of our implementation to quantify overheads and limitations. Our experiments indicate that for programs with modest mutation rates on shared data, applications can use futures to profitably exploit parallelism, without sacrificing safety.

This paper presents, QuickStore, a memory-mapped storage system for persistent C++ built on top of the EXODUS Storage Manager. QuickStore provides fast access to in-memory objects by allowing application programs to access objects via normal virtual memory pointers. The paper also presents the results of a detailed performance study using the OO7 benchmark. The study compares the performance of QuickStore with the latest implementation of the E programming language. These systems (QuickStore and E) exemplify the two basic approaches (hardware and software) that have been used to implement persistence in object-oriented database systems. In addition, both systems use the same underlying storage manager and compiler allowing us to make a truly applesto-apples comparison of the hardware and software techniques. 1.

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.

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

We describe and name a range of approaches to adding persistence to the Java programming language. Java is interesting in this regard not only because of the current excitement over it. Some relevant properties of Java include: its blend of static and dynamic features, its incorporation of object code into the environment, its offering of automatic storage management, its standardization of the object code format, its broad (but not exclusive) use of object orientation, and its use of a standard library. In considering approaches to adding persistence to Java, we offer a preliminary evaluation of the advantages and disadvantages of the approaches, and describe some directions we are pursuing in our own developments. We hope our descriptions and evaluations will be useful to others in understanding the attributes of systems and designs to be discussed at the workshop, or considered thereafter.

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

If persistent programming languages are to be accepted they must provide many of the standard features of traditional database systems, including resilience in the face of system failures in which the volatile database (in-memory databasebuffers) is lost. Ensuring the consistency of the database requires the generation of recovery information sufficient to restore the database to a consistent state after a crash. This paper examines a range of schemes for the efficient generation of recovery information in persistent programming languages, and evaluates their relative performance within an implementation of Persistent Smalltalk.

Priority inversion occurs in concurrent programs when low-priority threads hold shared resources needed by some high-priority thread, causing them to block indefinitely. Shared resources are usually guarded by low-level synchronization primitives such as mutual-exclusion locks, semaphores, or monitors. There are two existing solutions to priority inversion. The first, establishing highlevel scheduling invariants over synchronization primitives to eliminate priority inversion a priori, is difficult in practice and undecidable in general. Alternatively, run-time avoidance mechanisms such as priority inheritance still force high-priority threads to wait until desired resources are released. We describe a novel compiler and run-time solution to the problem of priority inversion, along with experimental evaluation of its effectiveness. Our approach allows preemption of any thread holding a resource needed by higherpriority threads, forcing it to release its claim on the resource, roll back its execution to the point at which the shared resource was first acquired, and discard any updates made in the interim.

The performance of many object-oriented database applications suffers from the page fetch latency which is determined by the expense of disk access. In this work we suggest several prefetching techniques to avoid, or at least to reduce, page fetch latency. In practice no prediction technique is perfect and no prefetching technique can entirely eliminate delay due to page fetch latency. Therefore we are interested in the trade-off between the level of accuracy required for obtaining good results in terms of elapsed time reduction and the processing overhead needed to achieve this level of accuracy. If prefetching accuracy is high then the total elapsed time of an application can be reduced significantly otherwise if the prefetching accuracy is low, many incorrect pages are prefetched and the extra load on the client, network, server and disks decreases the whole system performance. Access pattern of object-oriented databases are often complex and usually hard to predict accurately. The ...

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