The appearance of 64-bit address space architectures, such as the DEC Alpha, HP PA-RISC, and MIPS R4000, signals a radical shift in the amount of address space available to operating systems and applications. This shift provides the opportunity to reexamine fundamental operating system structure specifically, to change the way that operating systems use address space. This paper

E is an extension of C++ designed for writing software systems to support persistent applications. Originally designed as a language for implementing database systems, E has evolved into a general persistent programming language E was the first C++ extension to support transparent persistence, the first C++ implementation to support generic classes, and remains the only C++ extension to provide general-purpose lterators, In addition to its contributions to the C + + programming domain, work on E has made several contributions to the field of persmtent languages in general, including several distinct implementations of persistence. Thm paper describes the main features of E and shows through examples how E addresses many of the problems that arise in building persistent systems.

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.

This paper describes the design and implementation of the Ariel DBMS and it's tightlycoupled forward-chaining rule system. The query language of Ariel is a subset of POSTQUEL, extended with a new production-rule sublanguage. Ariel supports traditional relational database query and update operations efficiently, using a System Rlike query processing strategy. In addition, the Ariel rule system is tightly coupled with query and update processing. Ariel rules can have conditions based on a mix of patterns, events, and transitions. For testing rule conditions, Ariel makes use of a discrimination network composed of a special data structure for testing single-relation selection conditions efficiently, and a modified version of the TREAT algorithm, called A-TREAT, for testing join conditions. The key modification to TREAT (which could also be used in the Rete algorithm) is the use of virtual ff-memory nodes which save storage since they contain only the predicate associated with the memory n...

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

ion Dal's architecture, illustrated in Figure 2, is organized in multiple layers of abstraction to support the toolkit approach discussed earlier. At the highest level, users can interact with Dal's relational manager. Below that level is what we call the heap-file/indexing layer, which provides support for fixed-length and variable-length collections, as well as template-based Locks Logs System database Database file 1 Database file 2 Database file N Process 1 user code Dal library Virtual memory of process 1 Virtual memory of process 2 System physical memory Process 2 user code Dal library Log of updates to database Checkpoint images of database Figure 1. Architecture of the Dal system. Bell LabsTechnical Journal uWinter 1997 39 indexing abstractions. In general, at this level, a user does not need to interact with individual locks or latches. (A latchis a short-term lock implemented by a high-speed mutual exclusion mechanism.) Instead, the user specifi...

This paper presents the architectureof BeSS -- a high performance configurable database storage manager providing key facilities for the fast development of object-oriented, relational, or home-grown database management systems. BeSS is based on a multi-client multi-server architecture offering distributed transaction management facilities and extensible support for persistence. We present some novel aspects of the BeSS architecture, including a fast object referencetechnique that allows re-organization of databases without affecting existing references and two operation modes that an application running on a client or server machine can use to interact with the storage system -- copy on access and shared memory.

The paper presents a general model for persistent replicated object management and identifies what meta information about objects needs to be maintained by a naming and binding service to ensure that objects named by application programs are bound to only those object replicas which are in a mutually consistent state. These ideas are developed within the framework of a distributed system in which application programs are composed of atomic actions (atomic transactions) manipulating persistent (long-lived) objects.

This paper discusses the design and implementation of the E Persistent Virtual Machine (EPVM), an interpreter that provides support for persistent data access in the current version of the E programming language. Included are descriptions of both the EPVM interface and the major implementation tactics employed within EPVM. A novel pointer swizzling scheme that has been investigated in the context of E and EPVM is also described. Finally, a performance analysis of the key EPVM primitives is presented. 1. INTRODUCTION This paper discusses the current implementation of access to persistent data in the E programming language. E is a persistent, object-oriented programming language that was developed as an extension of C++ [Stro86] for use in the EXODUS project at the University of Wisconsin [Care89a]. The E language was originally designed for use in constructing database management system software; an overview of the design and motivation for E can be found in [Rich89a]. Basically, three...

We present formal specifications of a new abstraction, weak sets,whichcanbe used to alleviate high latencies when retrieving data from a wide-area information system liketheWorld Wide Web. In the presence of failures, concurrency, and distribution, clients performing queries may observe behavior that is inconsistent with the stringent semantic requirements of mathematical sets. For example, an element retrieved and returned to the clientmay be subsequently deleted before the query terminates. Wechose to specify formally the behavior of weak sets because wewanted to understand the varying degrees of inconsistency clients might be willing to tolerate and to understand the tradeoff between providing strong consistency guarantees and implementing weak sets efficiently. Our specification assertion language uses a novel construct that lets us model reachability explicitly# with it, we can distinguish between the existence of an object and its accessibility. These specifications were instrum...