Section: New Results
Information System Processes
Participants : Ciáran Bryce, Pierre Duquesnes.
A fundamental feature of software today is that it continuously needs to be modified – even after its deployment on client or server machines. Modifications might follow the appearance of new business requirements, the need to adapt the software to new hardware, or the need to re-engineer the software for efficiency or licensing issues. Urgent software modifications may also appear in the form of fixes for security holes and bugs. In today's world, the facility to modify existing software is as fundamental a requirement as the facility to build software in a modular, reusable-component fashion.
One of the founding principles of the object-oriented programming paradigm is inheritance. This technique enables a programmer to take a software component, and to design a new component based on this. For instance, a Double is a floating-point arithmetic concept that is built from the Number concept, with additional functionality. However, Double is an extension of Number; client systems that use Double are unaware of the new concept. Inheritance means that the new concept retains the inherent characteristics of the old concept. This is too restrictive for the bug fixes and the range of software modifications that need to be envisaged. The aim of inheritance is software extension; this is not the same requirement as software evolution. A mechanism is required for object-oriented systems that goes beyond inheritance.
Software systems are traditionally updated by applying a patch to the program binaries, and then rebooting the system. However, this supposes that the system can be stopped – something not evident for software that needs to run 24/7. Some servers get around this issue by tolerating minor interruptions and/or by duplicating hardware so that servers can be restarted independently in a cascading manner. Neither solution is complete satisfactory. Even more fundamentally, there is no model to guide the design and application of a patch from the original source code in a manner that the programmer can reason about the way the modification is applied, and the behavior of the system after update.
There has been some work on dynamic software update, where a modifications are made to programs while they execute. These approaches generally seek to replace functions or methods in running programs. The approach has the advantage of seeking to make program update usable in legacy systems. However, the approach does have complexities. First, in practice, the nature of modifications to be made might not be confined to the function or class. Second, function and class replacement is particularly hard to implement due to the risk of typing errors, synchronization errors, the presence of long-running functions like main.
Our work presents a language model for dynamic program update. The model permits a programmer to define stages of computation. Control flow passes from stage to stage, and a program update is modeled by funnelling control to a new set of stages. Making update explicit in the model helps avoid the complexity of existing dynamic software update methods. Further, the model allows the programmer to specify changes that can be made at program update as expressions in source code.
