Persistent object systems greatly simplify programming tasks since they hide the traditional distinction between short-term and long-term storage from the applications programmer. As a result, the programmer can operate at a level of abstraction in which short-term and long-term data are treated uniformly. It is important that such a persistent system be capable of being used concurrently; such concurrent usage may arise because of parallel process facilities in the programming language concerned, or because of multiple users of the same persistent store. Concurrent access has not been satisfactorily supported in existing persistent store implementations and a number of significant research issues remain to be investigated. This paper describes an architecture that supports concurrent access to a shared persistent object store. The persistent distributed architecture represented by our system exploits a number of the facilities provided by the Mach distributed operating system.

Persistent languages and systems provide the ability to create and manipulate all data in a uniform manner regardless of how long it persists. Such systems are usually implemented above a stable persistent store which supports reliable long-term storage of persistent data. In this paper we consider the issue of distribution of the persistent store across nodes. A number of existing persistent languages with support for distribution are described in terms of a taxonomy of distributed stores. It is shown that there are considerable difficulties with these systems, particularly in terms of scalability. A new mechanism based on the exportation and remote execution of procedures is then described. A key feature of this mechanism is that an exported procedure may dynamically bind to data in the remote store. It is shown that the mechanism alleviates most of the problems of existing systems and provides considerable flexibility. The paper concludes with some examples of practical use...

. The UniForM Concurrency Toolkit is a comprehensive library of abstract data types for shared memory and message passing communication that extends Concurrent Haskell with a concept of dynamic types, thread identity, thread local state and selective communication as found in CML. Notable features of the toolkit are its support for reentrant monitors, interactors providing iterative choice and the uniform representation of internal channel events as well as external tool events of the environment in the form of first class synchronous event values. 1 Introduction The UniForM Concurrency ToolKit 1 has primarily been designed to support the development of reactive systems using Concurrent Haskell [PJGF96]. The toolkit provides, partially backed up by a class system, a number of archetypical shared memory abstractions such as semaphores, locks and shared variables. The most important contribution, however, is the concept of reentrant monitors, whose main advantage over MVar's is that r...

. In the last three years we have been working with persistence and distribution, in particular migration of higher-level objects (such as procedures) between autonomous persistent programs. In this paper we introduce persistence and the suitability of Napier88 --- the persistent system we have used for our experiments --- as an agent language. We then present a few examples of opportunities and many more challenges that exist in the combination of persistence with agents. 1 Introduction The main motivation for this paper is our perception that free variables and persistence have not been properly addressed by the agent research community. Persistence is important because many of the examples presented in the agent literature include local or remote database access. Free variables are also of interest --- and unavoidable in a persistent environment --- because data and code are highly and strongly inter-connected in the persistent store. This paper is based on our experience with pers...

This paper describes the use of a persistent store to support incremental system construction. A single example is elaborated throughout the paper to introduce elements of the incremental construction mechanism. The essence of the technique is to permit assignment of executable program fragments to typed locations in order to change the behaviour of a program under construction. The technique described in this paper relies upon the existence of three features: a persistent store, updatable locations and first class executable values. The examples in this paper use the persistent programming language Napier88, but any language with these features could be used to construct such a system. 1. Introduction In many programming environments, the compilation units are syntactic entities which typically contain some data and a set of procedures (or functions) which provide access to that data. This approach is exemplified by packages in Ada [1] and Object Oriented Design Methodolog...

Name management is so fundamental to every aspect of computing that it is frequently overlooked or taken for granted. Our research is aimed at developing both models to improve understanding and mechanisms to improve practical application of name management approaches in various computing domains. One domain that seems to have particularly strong connections to name management is object technology for advanced software. Object technology has already proven very useful in our investigation of name management models and mechanisms. We also see great potential for beneficial application of improved name management mechanisms to object technology for advanced software. In this paper, we first outline our overall approach to research on name management and discuss some specific name management concerns arising in object technology for advanced software. We then illustrate the application of object technology in our efforts to construct name management models and mechanisms. Finally we give ...

Over the last 15 years a number of persistent language systems have been produced whose implementation relies on the persistence mechanisms provided by an underlying operating system. We have produced an operating system called Grasshopper expressly designed to support orthogonally persistent systems. In this paper we demonstrate how the mechanisms provided by Grasshopper may be used to implement a persistent version of the language Java.

Data Types ............................................45 11.1 Abstract Data Type Definition ................................... 45 11.2 Creation of Abstract Data Objects............................... 45 11.3 Use of Abstract Data Objects .................................... 46 11.4 Equality and Equivalence ........................................ 47 12 Files .............................................................48 12.1 File Literal ......................................................... 48 12.2 Equality and Equivalence ........................................ 48 13 Type any ........................................................49 13.1 Injection into Type any........................................... 49 13.2 Projection from Type any........................................ 49 13.3 Equality and Equivalence ........................................ 50 14 Environments ...................................................51 14.1 Creating a New Environment.......................

Research into persistent programming languages and systems in recent years has shown that the technology is useful for developing complex software in many problem domains. This paper explores the issues of adding persistence support to Ada, either as extensions to Ada 9X, or as an integral part of the next version of the language. 1. Introduction This paper explores the options for supporting persistence in Ada. In the introduction, we establish the setting for the paper by explaining why this is an issue worth considering. 1.1. The Ada programming language TheAda programming language arose from a US Department of Defence (DoD) initiative started in the mid 1970's to develop a High Order Language (HOL) suitable for embedded systems software. The original Ada language proposal, which was one of the four responses to the Ironman/Steelman requirements documents [47], was refined to a proposed standard [28,48] by 1980 and standardised in 1983 [49]. Our analysis of the requirements and s...

The name management capabilities currently provided by most existing persistent object systems (POSs) are rather limited. In particular, existing POSs tend to lack powerful and general mechanisms for forming, manipulating, controlling and reasoning about contexts. As a result, these POSs offer only weak or awkward support for large-scale data storage, multi-user computing, code reuse, interoperation of independently developed object stores and other similarly important classes of applications. As part of our work on improved name management for convergent computing systems, we have developed a framework for uniform treatment of the context and interface control facets of name management. In this paper we describe a realization of that framework, in the form of a shell-style user interface to a POS, that we are using to experiment both with the framework itself and with enhanced context control capabilities for POSs. 1 Introduction A convergent computing system is any system in which t...