David S. Munro

Stability in a Persistent Store Based on a Large Virtual Memory

Persistent systems support mechanisms which allow programs to create and manipulate arbitrary data structures which outlive the execution of the program which created them. A persistent store supports mechanisms for the storage and retrieval of objects in a uniform manner regardless of their lifetime. Since all data of the system is in this repository it is important that it always be in a consistent state. This property is called integrity. The integrity of the persistent store depends in part on the store being resilient to failures. That is, when an error occurs the store can recover to a previously recorded consistent state. The mechanism for recording this state and performing recovery is called stability. This paper considers an implementation of a persistent store based on a large virtual memory and shows how stability is achieved.

Garbage collecting the world: one car at a time

A new garbage collection algorithm for distributed object systems, called DMOS (Distributed. Mature Object Space), is presented. It is derived from two previous algorithms, MOS (Mature Object Space), sometimes called the train algorithm, and PMOS (Persistent Mature Object Space). The contribution of DMOS is that it provides the following unique combination of properties for a distributed collector: safety, completeness, non-disruptiveness, incrementality, and scalability. Furthermore, the DMOS collector is non-blocking and does not use global tracing.

Concurrent Shadow Paging in the Flask Architecture

The differing requirements for concurrency models in programming languages and databases are widely diverse and often seemingly incompatible. The rigid provision of a particular concurrency control scheme in a persistent object system limits its usefulness to a particular class of applications, in contrast to the generality intended by the provision of persistence. One solution is to provide a flexible system in which concurrency control schemes may be specified according to the particular task in hand, allowing the same data to be used in conjunction with different concurrency control schemes according to the needs of the application.

The Napier88 Persistent Programming Language and Environment

Persistent programming systems are designed as an implementation technology for long lived, concurrently accessed and potentially large bodies of data and programs, known here as persistent application systems (PASs). Within a PAS the persistence concept is used to abstract over the physical properties of data such as where it is kept, how long it is kept and in what form it is kept. As such it is seen as having a number of benefits in simplifying the task of PAS programming. Here, we describe the integrated design of the Napier88 persistent programming system and how Napier88 may be used to develop PASs.

Starting with termination: a methodology for building distributed garbage collection algorithms

We propose an effective methodology in which a distributed garbage collector may be derived from a distributed termination algorithm and a centralized garbage collector in a manner that preserves interesting properties of the original collector, such as completeness. To illustrate our technique, we show how two distributed termination algorithms, credit recovery and task balancing, may be suitably described; and then map four centralized garbage collectors: reference counting; mark/scan; a generational scheme; and the Mature Object Space collector (MOS) onto this description. The advantage of our approach is that by separating the issues of distribution and collection, we alleviate the difficulty of inventing, understanding, and comparing distributed garbage collection techniques.

A Layered Persistent Architecture for Napier88

In recent years a range of single programming language systems have been developed that are supported by a persistent store. Examples of such systems include Argus, Galileo, PS-algol and Smalltalk. Although each of these systems is based on a subtly different concept of persistence a common approach is to utilise a layered architecture. This paper presents the design of one such layered architecture that can be used to support a persistent object store where the protection is enforced by a high level type system. The architecture has been used to construct the persistent programming system for Napier88 and is powerful enough to support languages with similar type systems.

Scalable Surveillance Software Architecture

Video surveillance is a key technology for enhanced protection of facilities such as airports and power stations from various types of threat. Networks of thousands of IP-based cameras are now possible, but current surveillance methodologies become increasingly ineffective as the number of cameras grows. Constructing software that efficiently and reliably deals with networks of this size is a distributed information processing problem as much as it is a video interpretation challenge. This paper demonstrates a software architecture approach to the construction of large scale surveillance network software and explores the implications for instantiating surveillance algorithms at such a scale. A novel architecture for video surveillance is presented, and its efficacy demonstrated through application to an important class of surveillance algorithms.

Estimating camera overlap in large and growing networks

Large-scale intelligent video surveillance requires an accurate estimate of the relationships between the fields of view of the cameras in the network. The exclusion approach is the only method currently capable of performing online estimation of camera overlap for networks of more than 100 cameras, and implementations have demonstrated the capability to support networks of 1000 cameras. However, these implementations include a centralised processing component, with the practical result that the resources (in particular, memory) of the central processor limit the size of the network that can be supported. In this paper, we describe a new, partitioned, implementation of exclusion, suitable for deployment to a cluster of commodity servers. Results for this implementation demonstrate support for significantly larger camera networks than was previously feasible. Furthermore, the nature of the partitioning scheme enables incremental extension of system capacity through the addition of more servers, without interrupting the existing system. Finally, formulae for requirements of system memory and bandwidth resources, verified by experimental results, are derived to assist engineers seeking to implement the technique.

Mosaic: a non-intrusive complete garbage collector for DSM systems

Little work has been done in garbage algorithms for distributed shared memory systems. Mosaic is a safe and complete garbage collection system that collects garbage in object systems that are implemented above page-based distributed shared memory systems. It is non-intrusive in its impact on application performance. Mosaic partitions the virtual address space into separately managed regions, which form the basic unit of object storage. Garbage collection operates by moving objects between these partitions in a manner that associates live objects together, leaving unreachable objects behind so that partitions may be reused. To provide for safe operation of the collector, a distributed updated protocol maintains sufficient local knowledge of pointer duplication and destruction to allow safe determination of object reachability without the need to globally trace the object space. Mosaic exploits the semantics of pointer operations in type-safe object languages to allow for a weakened consistency model of pointer update during garbage collection.

Instances and Connectors: Issues for a Second Generation Process Language

Over the past decade a variety of process languages have been defined, used and evaluated. It is now possible to consider second generation languages based on this experience [1, 3,4]. Rather than develop a second generation wish list this position paper explores two issues: instances and connectors. Instances relate to the relationship between a process model as a description and the, possibly multiple, enacting instances which are created from it. Connectors refers to the issue of concurrency control and achieving a higher level of abstraction in how parts of a model interact. We believe that these issues are key to developing systems which can effectively support business processes, and that they have not received sufficient attention within the process modelling community. Through exploring these issues we also illustrate our approach to designing a second generation process language.1