Huw Evans

Zones, contracts and absorbing changes: an approach to software evolution

This paper describes a novel approach to managing the evolution of distributed, persistent systems at run-time. This is achieved by partitioning a system into disjoint zones, each of which can be evolved without affecting code in any other. Contracts are defined between zones, making type-level interdependencies and inter-zone communication explicit. Programmer supplied code is added to the running system, at the boundary between zones, to constrain the scope of changes. A change methodology is presented which the software engineer uses to help describe and manage the evolution of the system. Knowledge of the application semantics is essential when evolving a system and our approach allows the engineer to concentrate on these semantic aspects of change. Our Java-based demonstration platform and methodology reduce or remove some of the burdensome tasks the software engineer is normally expected to perform when changing a system, making evolution more tractable.

DRASTIC: A run-time architecture for evolving, distributed, persistent systems

Modern systems must be adaptable — to changing requirements, bug-fixes, new technologies and reconfiguration. For critical applications this must be possible at run-time; for complex applications it should be limitable to major sub-divisions of the system. The DRASTIC architecture addresses these goals by exploiting object persistence and distributed systems implementation techniques. It enables run-time changes of types, implementations, and the system configuration. This is based on a novel architectural abstraction of locality for evolution, called the ‘zone’. Contracts between zones automatically limit the visibility of such changes between zones. We present work in progress on DRASTICs computational model and run-time system, illustrating support for software evolution and highlighting key features of our current implementation.

The pervasiveness of evolution in GRUMPS software

This paper describes the evolution of the design and implementation of a distributed run‐time system that itself is designed to support the evolution of the topology and implementation of an executing, distributed system. The three different versions of the run‐time architecture that have been designed and implemented are presented, together with how each architecture addresses the problems of topological and functional evolution. In addition, the reasons for the rapid evolution of the design and implementation of the architecture are also described.

Garbage collection and memory management

This document is the report for the OOPSLA97 Workshop on Garbage Collection and Memory Management. The one-day workshop was organ&d by Paul R. Wilson of the University of Texas at Austin, USA and Peter Dickman and Huw Evans of the University of Glasgow, Scotland. Fifteen papers were accepted and eighteen presentations were made. The sessions were divided into: Instrumentation and Evaluation; Java GC Implementation; Finding Stuff, Commercialising GC; Distributed Garbage Collection, Miscellany, Workshop Wind-up.

Instrumenting Bytecode for the Production of Usage Data

We have taken the process of software instrumentation, normally used in the creation of profiling and debugging tools, and applied it to the production of usage data for user-computer interaction studies. This paper describes the design and evaluation of a prototype tool called iGuess, that enables an investigator to discover which methods are used within a Java application when particular tasks are carried out, and instrument these to produce usage data. A key feature of the system is that an application can be instrumented without any need for access to the source code. In this paper we describe the system’s functionality, briefly explain how it works and present the results of an early informal evaluation.

Dynamic on-line object update in the Grumps system

This paper describes the Grumps approach to the on-line upgrading of objects in a distributed system. This is supported by three main, well-known ideas: core code abstractions are defined in terms of Java interfaces and not classes; as many decisions as possible are delayed until run-time; and object containers are used to manage groups of objects at run-time. The advantage of the first idea is that it introduces a level of indirection in between what an object does (in terms of its interface) and how that is accomplished (in terms of its class). The advantage of the second idea is that it does not force the programmer to make decisions at compile-time that may be hard to change later; they can change their mind and easily alter the systems behaviour at run-time. The use of the third idea allows objects to be grouped together and the container can act as a representative for or abstraction over the contained objects. The major Grumps abstractions are described, an example object upgrade is presented and the advantages and disadvantages of this approach are discussed.

DRASTIC and GRUMPS: design and implementation of two run-time evolution frameworks

The paper describes two different approaches to supporting and managing the run-time evolution of distributed applications. The evolution models and implementations of the DRASTIC and GRUMPS projects are presented and contrasted. Within the context of related work, the paper argues that there is too little support for software engineers in constructing distributed applications that may be evolved at run-time. DRASTIC and GRUMPS address this problem by providing programming language layers that place the support for run-time change at the centre of an applications design. The paper goes on to present four core ideas that are generally applicable for the construction of run-time support layers. In addition, the lessons learned from conducting this research are discussed. The core ideas and the lessons learned are used to derive ten principles that may be exploited when designing other run-time evolution support systems. The paper ends with a discussion of the open issues that face those working in the field of distributed run-time evolution support.

Peer-to-Peer Programming with Teaq

This paper introduces Teaq, a new peer-to-peer programming model and implementation that places processes into a self-healing, ordered spanning tree, across which distributed object queries are routed. The programmer has control over where in the tree their process resides, how their queries are routed through the tree, and how result objects are generated and passed back to the query initiator. Default implementations are provided that the programmer may specialise. This paper introduces the two main algorithms for maintaining the tree and routing queries.

JavaCloak: Reflecting on Java Typing for Class Reuse Using Proxies

We discuss problems caused by the limitations of Java’s reflection mechanism in supporting the specialisation of run-time program behaviour in Java-Cloak. JavaCloak allows programmers to specialise the run-time behaviour of externally-developed code by using pre-generated source-level proxy objects. These proxy objects are of the same type as the original objects that they wrap. The runtime specialisation is achieved in two phases. Firstly, the programmer generates the proxies and tailors them to their local needs. The programmer then generates a JAR file of these proxy classes which is placed at the very start of the applications CLASSPATH variable. The virtual machine is thus diverted into loading the proxy classes instead of the original classes. At runtime the Java-Cloakrun time system accesses the wrapped classes and mediates object creation and method calls across the proxy/original boundary.