Persistent stores

The persistence abstraction can be extended in order to abstract over all the physical properties of data. Therefore, the implementation of a persistent store must be transparent to its users. That is, the size, speed and components of a persistent store are all hidden from a user by the persistence abstraction. As a consequence of this, a persistent store has certain perceived attributes such as unbounded size, infinite speed and stability. The main technical problems encountered when constructing a persistent store involve the simulation of these perceived attributes.

1.5.2.1 Store size

The ideal persistent store is of unbounded size. If it were not, its size could be determined by a program that created objects until the store was full. This would violate the persistence abstraction. Unbounded size can be simulated by using mechanisms such as garbage collectors and stacks to reclaim unused space. However, the particular choice of mechanisms is dependent on the type of computation being performed and the scale of the persistent store. For example, a persistent store supporting first class procedures may not be able to use a stack allocation scheme for recording all procedure activations. Similarly, an extremely large persistent store that is in continual use, may be constrained to use a garbage collector that operates concurrently with the store's users.

1.5.2.2 Store speed

The conceptual requirement on a store is that it is infinitely fast but, technologically, this is not possible. The only solution to this problem is to divide the persistent store into

components that can operate concurrently. In this way, the total performance of the store may be increased although it can never approach the ideal performance.

1.5.2.3 Store stability

The components of the persistent store are hidden so any failures must also be hidden. There are a wide variety of techniques that can be employed to simulate stable storage, but they all use the basic technique of maintaining more than one copy of the persistent store on non-volatile media. This may be performed by employing a strategy for regularly dumping the persistent store or always maintaining multiple copies of the persistent store on different disks. However, no stability mechanism can guarantee total stability, since all the copies of a persistent store may be subject to simultaneous damage.

1.6 Overview

The remainder of this thesis is concerned with the architectural support required to provide a type secure persistent object store. In particular, it describes the development of such a store as part of an architecture to support experiments in concurrency, transactions and distribution.

The architecture of the store has been designed to provide each distinct architectural mechanism as a separate architecture layer that must conform to a specified interface. The motivation for this design is two-fold. Firstly, the particular choice of layers greatly simplifies the implementation of the resulting architecture. For example, in a traditional computer system, a segmentation mechanism may be required to provide a large address space, organise the address space into logical objects and also provide a protection mechanism for the address space. In the layered architecture these three mechanisms are provided by three separate layers each of which need only implement a single mechanism.

The second motivation for the layered design is that it can support experimental architecture implementations. This is achieved by ensuring each layer conforms to its specified interface. Consequently, it is possible to experiment with the implementation of an individual layer without affecting the implementation of the remaining architecture layers. A further benefit of the layered design is that the reduced complexity also reduces the cost of conducting experiments. Thus, the layered architecture is a convenient vehicle for experimenting with the implementation of a persistent object store.

Chapter 2 presents a short review of the development of the various techniques that can be employed in constructing a type secure persistent store. These include techniques that can be employed to provide a type secure store, to simulate a store of unbounded size, to simulate an infinitely fast store and to simulate a stable store. It concludes by presenting three example systems that demonstrate how a selection of these techniques can be combined to construct a type secure persistent store.

This is followed in Chapter 3 by a description of the CPOMS. The CPOMS was designed and implemented as an experiment in constructing a persistent object store for use with the programming language PS-algol. As a result of analysing the advantages and disadvantages of the CPOMS, a layered architecture was designed. The evolution of this design is presented in Chapter 4.

A significant factor in the design of any computer architecture is the feasibility of implementing it. In Chapter 5, some of the practical issues relating to implementation are discussed. As a result, an optional layer is described that permits the complete layered architecture to be efficiently implemented with or without the support of special purpose hardware.

To demonstrate the feasibility of the architecture, Chapter 6 presents a description of the first implementation used by the programming language Napier[bro88a,mor88]. This is supplemented in Chapter 7 by a description of how the architecture could be used to support experiments with distribution. To conclude the description of the layered architecture, Chapter 8 presents a technique for tuning the architecture layers to reflect a particular choice of system configuration.

Finally, Chapter 9 presents a summary of the research undertaken and an indication of the directions for possible future research.

2 Implementation issues

The provision of a type secure persistent store must address the following issues: a) type security,

b) store size, c) store speed and d) store stability.

Each of these issues present problems that have been well known for a number of years and to which many different solutions have been proposed. However, complete systems that attempt to provide a type secure persistent store are relatively recent and few in number[alb85a,lis84,that86]. The four issues will be discussed separately and their development illustrated by reference to a wide range of existing systems.

2.1 Type security

The provision of a type secure store requires that all programs operating on the store conform to some predefined rules. These rules are designed to control which data may be accessed by a program and how that data may be interpreted. The rules may be enforced in a number of ways, ranging from using special hardware to control access to certain areas of the store, to using a compiler to constrain the operations attempted by a program.

2.1.1 Separate address spaces

One of the basic techniques which may be adopted to control access to areas of store is the implementation of multiple address spaces. Initially, this technique was used to ensure that separate programs running on the same computer could not, accidentally or otherwise, corrupt each other. In addition to giving each program a separate address space, many computer architectures added two or more privilege levels[buc78,sch72,str69]. This provided a further level of protection to those parts of an operating system that have to be shared with a user's program. For example, the DEC VAX architecture[dec83] supports

separate address spaces for programs, together with the four privilege levels: user mode, supervisor mode, executive mode and kernel mode.

A further use of separate address spaces within traditional computer architectures is the division of a program's own address space. For example, a UNIX system will divide a program's address space between read only executable code and modifiable data[rit74]. This division is intended to prevent a program accidentally modifying the code it is executing.