Check out the new USENIX Web site. next up previous
Next: Address Translation Taxonomies Up: Address Translation Strategies in Previous: Address Translation Strategies in

Introduction

The Texas Persistent Store provides portable, high-performance persistence for C++ [17,8], using pointer swizzling at page fault time [24,8] to translate addresses from persistent format into virtual memory addresses. Texas is designed to implement and promote orthogonal persistence [1,2]. Orthogonal persistent systems require that any arbitrary object can be made persistent without regard to its type; that is, persistence is viewed as the storage class3 of an object rather than as a property of its type. In other words, persistence is a property of individual objects, not of their classes or types, and any object can be made persistent regardless of its type. In contrast, class-based persistent systems require that any type or class that may be instantiated to create persistent objects must inherit from a top-level abstract ``persistence'' class, which defines the interface for saving and restoring data from a persistent object store.

Texas uses pointer swizzling at page fault time as the primary address translation technique. When a page is brought into memory, all pointers in the page are identified and translated (or swizzled) into raw virtual addresses. If the corresponding referents are not already in memory, virtual address space is reserved for them (using normal virtual memory protections), allowing for the address translation to be completed successfully. As the application dereferences pointers into non-resident pages, these are intercepted (using virtual memory access protection violations) and the data is loaded from the persistent store, causing further pointer swizzling and (potential) address space reservation for references to other non-resident data. Since running programs only see pointers in their normal hardware-supported format, conventionally-compiled code can execute at full speed without any special pointer format checks.

This page-wise address translation scheme has several advantages. One is that it exploits spatial locality of reference, allowing a single virtual memory protection violation to trigger the translation of all persistent addresses in a page. Another is that off-the-shelf compilers can be used, exploiting virtual memory protections and trap handling features available to normal user processes under most modern operating systems.

However, as with any other scheme that exploits locality of reference, it is possible for some programs to exhibit access patterns that are unfavorable to a coarse-grained scheme; for example, sparse access to large indexing structures may unnecessarily reserve address space with page-wise address translation than with more conventional pointer-at-a-time strategies. It is desirable to get the best of both worlds by combining coarse-grained and fine-grained address translation in a single system.

In Texas, we currently support a fine-grained address translation strategy by using smart pointers [18,7,13] that can replace normal pointers where necessary. Such pointers are ignored by the usual swizzling mechanism when a page is loaded into memory; instead, each pointer is individually translated as it is dereferenced using overloaded operator implementations. The mixed-granularity approach works well, as shown by experimental results gathered using the OO1 benchmark [4,5].

The remainder of this paper is structured as follows. In Section 2, we describe existing well-known address translation taxonomies put forth by other researchers, and motivate the need for a general classification of persistence presented in Section 3. In Section 4, we discuss issues about fine-grained address translation techniques, and why we believe that a pure fine-grained approach is not suitable for general use. We describe the implementation of mixed-granularity address translation in Texas in Section 5 and the corresponding performance results in Section 6, before wrapping up in Section 7.



Footnotes

... class3
A storage class describes how an object is stored. For example, the storage class of an automatic variable in C or C++ corresponds to the stack because the object is typically allocated on the data stack, and its lifetime is bounded by the scope in which it was allocated.

next up previous
Next: Address Translation Taxonomies Up: Address Translation Strategies in Previous: Address Translation Strategies in

Sheetal V. Kakkad