Background of The Model of Persistence By Location

Conventional persistent systems, such as file systems, databases or the WWW, cannot support persistent object computing, since they support no abstraction of persistent objects. As a result, the programmer has to take special treatments for the creation and manipulation of long-term objects: translate their data resident in memory into a format suitable for long-term storage and save the translated data into long-term storage. The concept of orthogonal persistence [] introduced a uniform manner of the creation and manipulation of objects irrespective of their lifetime and data types. That is, the programmer can use a single unified manner to create and manipulate persistent objects and transient objects, whatever data types these objects belong to. This concept led to some persistent models, among which the Persistence By Reachability (PBR) model [] is the most popular one. For example, many orthogonal persistent systems such as PerDiS [], PJama [], Thor [], Objectivity/Smalltalk [] were built on this model.

In PBR, an object is persistent if and only if it is reachable from a persistent root. A persistent root is a distinguished, named persistent object, from which a garbage collector [] can discover all reachable objects. Tightly relying on the garbage collection mechanism, a PBR system can obtain all reachability information and then decide and maintain persistent objects. In PBR, all objects can potentially be persistent objects.

However, garbage collection requires special compiler cooperation so that the garbage collector can recognize object formats. In some popular languages like C or C++, the compiler generates no extra format information and supports garbage collection poorly. As a result, PBR is not suited for these uncooperative languages though some solutions [] were put forward. On the other hand, implementing a garbage collector is always a hard job, leading to a notion that PBR is a luxury that a "real" system programming language cannot afford [].

What is more, most PBR systems use pointer swizzling [] to take address translation between object identifiers (OID) and object addresses. Pointer swizzling usually relies on special compiler supports or memory protection mechanisms like page faults, memory mapping and so on. With the consideration of cost, low-cost hardware such as consumer electronics or communication equipments cannot afford special compiler supports or memory protection. Consequently, PBR is not suited for low-cost hardware.

To address these problems mentioned above, a lightweight persistence model is designed for implementing nested object stores to offer Persistence By Location (PBL). The PBL model does not rely on garbage collection, special compiler cooperation, and pointer swizzling. In PBL, each object store is a nested store, capable of containing sub stores and potentially having an unlimited capacity. Objects are resident in a multi-level object space and addressed with path-like, variable-length object identifiers. The PBL model introduces "At Storage" creation: the programmer uses creation methods of stores instead of the storage allocator to create persistent objects. This model has leaded to a few lightweight object containers built with the Rambler OS project, and the experience shows that the PBL model is lightweight and easy-to-implement.

More detail information on PBL can be found in paper "Persistence By Location: A Lightweight Persistence Model for Supporting Nested Object Stores with Potentially Unlimited Capacity".