Identifying stable store addresses

To support the use of the address translation procedure, the interface also describes how a stable store address may be differentiated from a main memory address. The convention adopted is to record stable store addresses as illegal main memory addresses. For example, when an object is copied from the heap of persistent objects each of its address fields may be negated, thereby transforming their contents into illegal main memory addresses.

5.3 Conclusion

The extensions to the architecture, described above, preserve the independence of the layers with just one exception. The abstract machine implementation must be tailored to operate either with a heap in main memory or a heap in stable storage. However, the implementation of an abstract machine, whether by a code generator or an interpreter, is always hardware dependent so this one loss of layer independence was considered acceptable. In either case, the potential of the architecture for experimentation is not significantly affected.

6 A software implementation of the architecture

This chapter describes the first implementation of the persistent object store supported by the layered architecture. The description is divided into five parts:

a) the relevant features of the abstract machine, b) the main memory heap,

c) the heap of persistent objects, d) the stable storage, and e) the non-volatile storage. 6.1 The persistent abstract machine

The abstract machine is designed to support the execution of PAIL programs. PAIL can support a wide range of block structured programming languages some of which may provide first class procedures, polymorphism and abstract data types. An example of a programming language that provides all three is Napier[mor88J. Hence, the abstract machine must be able to support first class procedures, polymorphism and abstract data types.

A consequence of supporting first class procedures is that variables declared within a block may be retained beyond the normal life time of the block, as part of a procedure’s static environment. In a traditional computer architecture, the storage associated with a block is allocated from a stack and automatically recovered when the code for the block has been executed, releasing the storage associated the variables declared within the block. To support languages with first class procedures, the abstract machine implements the block retention mechanism used by the PS-algol abstract machine[psa85].

The block retention scheme, supported by the abstract machine, is based on the creation of a separate persistent object for each block. The object contains the stack associated with the

block’s execution and is known as a frame. To complement the use of separate stack objects, all executable code is also in the form of separate persistent objects, one per procedure. An instance of a procedure is represented by two object addresses, one addressing the procedure's code object and one addressing the procedure’s static link. This is known as the closure of the procedure.

When a procedure is called or a block is executed a new frame is created. The frame's dynamic link is the address of the caller’s frame. Hence, all frames that form the dynamic chain are reachable from the frame of the executing procedure or block. This frame is known as the current frame. Similarly, the frames that form the static environment of a procedure are reachable via the procedure's static link. When a procedure or block terminates, the associated frame is no longer part of the dynamic chain. Unless the frame is to be retained as part of a procedure’s static environment, it is no longer reachable from the program and may be garbage collected. Thus, the garbage collector can automatically destroy or retain a frame as appropriate.

A description of the implementation techniques that support polymorphism and abstract data types is given by Dearle[dea88]. They are not described here since they are not relevant to the implementation of the persistent object store.

In addition to supporting PAIL, the abstract machine is constrained to use the persistent object store as its only available storage. This requires all the storage used by the abstract machine to be mapped onto persistent objects and it prohibits the use of known addresses to access predefined objects such as error handling procedures or literal values.

To support the use of predefined objects, the abstract machine maintains a special object that is large enough to contain the address of every predefined object that may be required. When the architecture is first used, the abstract machine creates the special object and places its address in the root object of the heap of persistent objects. Thereafter, the special object

can be accessed via the root object, whose address is provided by the interface to the heap of persistent objects. The predefined objects can then be accessed via the special object.

The combination of the block retention scheme and the persistent object store has an important consequence for the operation of the abstract machine; in that there is no separation of the available storage between a program’s data and a program’s dynamic state. In a traditional computer architecture, this division of storage may be in the form of a heap and a stack. When either the heap or stack is exhausted a program will fail even if there is storage available in the other. The advantage of eliminating the division is that a program will only fail when the entire storage has been exhausted.

The other features of the abstract machine are not relevant to the implementation of the architecture’s persistent store and are described elsewhere[bro88a].