Architectures for persistence

Gordon Russell, Paul Cockshott
1993 Microprocessors and microsystems  
Four well known persistent architectures are described by Gordon Russell and Paul Cockshott followed by a discussion on the attributes of an ideal system Persistent object oriented architectures have been researched for many years, deriving initially from the Manchester University Atlas machine. In reality, however, few actual implementations of persistent architectures exist In the first half of this paper an examination of four well known designs is carried out, name/y the System/38, Monads,
more » ... utaborand the Rekursiv. Each machine's object management model is explained, along with an analysis of the design decisions made. Following this, a discussion concerning the idea/ persistent architecture is presented, suggesting design decision which should be considered in any future persistent architecture. persistence object oriented architecture The idea of architectural support for persistent programming derives ultimately from the work of Tom Kilbum et al.' on the Manchester University Atlas computer. They introduced the idea of what was termed a single level store: a notion that is now more familiar to us as virtual memory. During the 1950s machines used a variety of different store technologies: Williams tubes, mercury delay lines, magnetic cores and moving magnetic devices. Although these media differed considerably in their response times, they were all used in the same conceptual fashion, as the primary store of the machine. For instance, an earlier machine by Kilburn et al.' at Manchester had combined, the then very new, transistors with a magnetic drum for its main instruction store. As a consequence of using drums its instruction cycle was slow at some 30 ms, but this was partially offset by the cheapness of drum store in comparison to its competitors. The single level store of Atlas was introduced as a means of making a drum store perform at almost the speed as the more expensive cores. The drum continued to act as the main store, but pages of it were automatically transferred on use to one of a small number of page frames implemented as magnetic cores. At this early period of development, computers were still seen primarily as number processing machines rather than as repositories for long term data. Although, by 1960, all the main memory technologies were based on magnetic effects and thus non-volatile, this aspect was not seen as being of any great significance. The drums that provided the main store of the Atlas were not used to hold long term information. Data to be processed was kept offline on tapes. The emphasis changed with the development of disc stores, which were from the start seen as long term stores. In consequence, when people first tried to develop interactive, virtual memory operating systems such as Multics3 and Emas4, they attempted to integrate discs and short term memory into a single level store. Ideally one would have liked to incorporate all of the discs as part of the permanent address space of the machine. In that case a disc file would just be a particular range of addresses. Two problems prevented a simple implementation of this approach: l The size of the discs exceeded the address space provided by the underlying machine architecture. l If a fixed range of addresses were allocated to a file, it was impossible to allow the file to grow. The EMAS system, for example, was initially implemented on ICL machines whose basic architecture was a copy of the IBM 360 series5. This restricted its address space to 24 bits or 16 Mbytes, far too little for a disc farm. The answer adopted was to allow files to be temporarily mapped into the address space of a process, a method that has recently been included in implementations of Unix'. The answer to the problem of mapping dynamically growing files could in princple be solved by segmentation, as was advocated in lliffe , and used in Multics and the later versions of Emas that were implemented on the 2900 series* machines. A file could now be made equivalent to a segment and allowed to grow up to the maximum size of a segment, but this just created new problems. The segments were smaller than large files, and there were fewer segments available than there were files. This early experience with operating systems showed that graceful integration of non-volatile store into machine architectures required: l A segmented architecture l A large number of segments l A large segment size. 0141-9331/93/030117-I 4 0
doi:10.1016/0141-9331(93)90042-6 fatcat:3ed7krl6hvbzlizxhgkc32xlga