On-Line Software Version Change Using State. Transfer Between Processes. Deepak Gupta. Pankaj Jalote. Department of Computer Science and Engineering

Transcription

1 On-Line Software Version Change Using State Transfer Between Processes Deepak Gupta Pankaj Jalote Department of Computer Science and Engineering Indian Institute of Technology Kanpur ; India Abstract The usual way of installing a new version of a software is to shut down the running program and then installing the new version. This necessitates a sometimes unacceptable delay during which service is denied to the users of the software. An on-line software replacement system replaces parts of the software while it is in execution, thus eliminating the shutdown. In this paper, we describe a system for on-line software version change for software written in the C language. When the change is initiated by the user, the system instantiates a new process with the new version of the software, transfers state from the old process to the new one at an appropriate time, and transfers the control to the new process. The user sees a minimal delay in this switchover. Keywords: Software enhancement, New version installation, Process state, On-line change, Continuously operating software. Introduction It is a well known fact in software engineering that programs undergo changes during their lifetime. These changes may be for bug correction, eciency improvement or functional enhancement. The change is usually eected by stopping the currently running program and installing the new version. This necessarily implies a denial of service to the users of the software while the switchover is being made. In critical applications, this delay is not acceptable. For such systems it is desirable to have an on-line software modication system which eliminates the system shutdown for installing a new version of the software, thus allowing continuous service to the users of the software.

2 This problem is dierent from the problem of conguration control [1] and version control [2], which are essentially means to manage the changes made during the development of software. The goal of these techniques is to prevent uncontrolled changes and extreme proliferation of program versions. On the other hand, on-line replacement deals with the problem of installing new software version after the development is complete. There are systems that allow exible interconnection of software components to form the complete system [3, 4, 5]. Though such systems allow exible interconnection of components, they frequently require interconnections to be specied before execution and do not usually permit changes to modules while the software is executing. Some systems allow the conguration of a distributed program to be changed dynamically by reassigning processes or modules to dierent nodes and by adding and deleting links, processes etc. dynamically[6, 7, 8, 9, 10]. A few approaches have been described for on-line software version change [11, 12, 13, 14]. The system described in reference [11] is restricted to dynamically changing the implementation of an abstract data type. The data representation within these data types is changed by appropriate conversion routines to suit a new code version, on demand. The DAS operating system [12] has the capability to modify procedures of a running program if the parameters and the return value of the procedures to be changed do not change across versions. DY- MOS [13] is a dynamic modication system comprising of a source code manager, an editor, a compiler and a run-time system to support on-line change. It requires a complicated locking protocol for every procedure invocation regardless of whether an update is being performed or not. PODUS [14, 15] is a dynamic updating system which has been shown to be scalable to the distributed case [16]. Most of these systems use indirect addressing tables to link the dierent modules. These tables are dynamically changed if a module has to be replaced by a new version. The changing of the table is done in a manner that it does not cause any inconsistencies. The major drawback of this approach is that the mechanisms used for dynamic updating are complicated and require new compilers and linkers to be written. In this paper, we describe a new approach for on-line software replacement and provide a theoretical framework for on-line modication of programs. We also describe a prototype implementation of our approach. Our basic approach to dynamic program version change is as follows. When a new version of the software is to be installed, a new process is created by the system with the new software. When none of the functions which have changed across 2

3 versions is on the run-time stack, the system transfers the state of the old process (running the old software) to the new process (running the new software) and kills the old process. The user sees no discontinuity in the service of the software and only a marginal time overhead is imposed by the system. The system has currently been implemented on a Sun 3/60 and has been designed for C programs. However, it can easily be extended for other procedural languages and can be ported to other systems running Unix. The major advantage of our approach is that it lends itself to a very simple and ecient implementation and no special compiler or linker is required. The current implementation is just about 1650 lines of C code. Valid and Complete Changes Clearly, arbitrary changes to the software cannot be allowed if we want to transfer state information from the old process to the new one. For example, on-line software replacement may not be feasible if the new version of the software is an entirely dierent program performing altogether dierent computations. In this section we study the requirements that must be satised if the change is to be installed on-line. Let the program consist of a set of functions F 1 ; : : :; F n : For explaining the underlying ideas and restrictions needed, we assume that during change no new functions are added and only existing functions are modied. Denition 1 A change to is dened as the set of ordered pairs of functions of that are to be changed and their new versions. Thus, def = f(f i ; F 0 ) j F i i 2 ; F 0 is the new version of F i i g Denition 2 The new version of under the change is dened as def = (? A) [ B where, and A = ff i j (F i ; F 0 i ) 2 g B = ff 0 j (F i i ; Fi) 0 2 g Let and be specied as P fg Q and P 0 f g Q 0 respectively, where Q (Q 0 ) is the desired post-condition of ( ) and P (P 0 ) is its required pre-condition. An on-line change 3

4 made to at time t(t > 0) is conceptually equivalent to the following sequence of steps. The execution of the program is started with the pre-condition P true. At time t, the execution is stopped and the program code is replaced by the code of (the state of the process executing the program remains the same). Then the execution is resumed from the existing state (but with new code). Suppose the execution of the program is started from an initial state satisfying I, such that I ) P, and I ) P 0. That is, from the initial state, either or could be successfully executed. An on-line replacement is considered valid if the nal state produced by the system is either the state that would be produced by executing completely, or the state that would be produced by executing completely. We now formally dene a valid change. Denition 3 An on-line change made to at some time t is said to be valid if either the post-condition Q 0 of or the post-condition Q of is true when the program terminates. Whether a change is valid or not depends on the nature of the change (i.e. what has been changed), and the time when the change is installed. While the former restricts the changes allowed to a program, the latter restricts when the transfer of state from the old process to the new process can occur. Since, a change in which Q holds on termination is a special case included in the denition for the sake of completeness (a change may be installed towards the very end of execution, and therefore may not have any eect on the nal system state), from now on we will focus on the change due to which Q 0 holds on termination. Since a change in one function without a corresponding change in some related functions may take the system to a state not satisfying Q 0, the change of a function might require a corresponding change in another function. In other words, the set of functions to be changed must be \complete". We now dene the notion of completeness of change and then relate it to the validity of an on-line change. Let Q i (Q 0 ) represent the post condition of the function i F i (F 0), and P i i(p 0 ) represent the weakest precondition [17] needed for the function to satisfy i the postcondition after execution. Let (F i ) denote the set of functions that may call the function F i in the program, i.e. (F i ) = ff j 2 j F j may call F i g Denition 4 A change to is said to be complete if the following two conditions hold for all (F i ; F 0 i ) 2 and for every F j 2 (F i ) such that F j has not changed across versions i.e. there is not a pair of the form (F j ; F 0 j ) in : 4

5 1. Let S be the post-condition that the function F j expects F i to satisfy. Then Q 0 i ) S. 2. Let R be the pre-condition with which F j calls F i. Then R ) P 0 i. The rst condition states that the functionality of the new version of a function must be a superset of what a caller expects. If this is not true, then the change is not transparent to the caller which must consequently be modied. The second condition requires that the new version should be able to perform its function under the conditions in which a caller calls the old version. If this is not true, then the caller must know about this and will have to be modied to call it under the new conditions. Let us now consider the second aspect of a valid change, namely the timing of the change. If is complete, then if the change is installed at a time when no function in is executing, the execution will eventually terminate in Q 0 (or Q), since the rest of the functions are unchanged. We now state a sucient condition to ensure that an on-line change is valid. Let rt (t) denote the set of procedures of that are on the run time stack of at time t. Proposition An on-line change made to at a time t is valid if : 1. is a complete change for. 2. 8(F i ; F 0 i ) 2 F i 62 rt (t): In this paper, we do not attempt a formal proof of the above proposition but its truth can be argued as follows. The second condition ensures that the functions in progress at time t are unchanged across versions. Any changed function called now will be called under the conditions that its old version would expect. Since this condition implies the pre-condition of the new version, it will work correctly and the condition that will hold after it returns will be stronger than the one that would have held had the change not been made. This will ensure that the future executions of any changed (or unchanged) functions will also work correctly. Note that the above conditions imply that the main function of the program can never be changed since it will always be on the run time stack during the execution of the program. However, in a well-structured program, most of the work is done by low level functions, and it will usually not be required to change the main function. So far, we have assumed that the set of functions remains the same for the two versions of the program but the analysis can readily be extended to deletion and addition of functions. 5

6 This can be done by adding dummy functions. In the case where new functions are added in the second version, dummy (empty) functions are added to the rst version. In the case where functions are deleted, dummy functions are added to the second version. Note that these dummy functions are needed only to specify valid and complete changes in our framework. As we will see, they are not needed in the implementation. If a function F has been added, then its rst version (the dummy) can never be on the run-time stack at any time and it also has no callers. Thus including or not including this function in the set of changes makes no dierence to either the validity or the completeness of the change. If a function F has been deleted, all its callers have to be modied and hence included in the set of changed functions. Clearly, F can not be on the run-time stack if none of its callers is. Again this implies that the completeness of the change is not aected by including or not including F in the set of changes. System Design Our approach to on-line version change is dierent from the traditional one of dynamic linking. The basic idea is to transfer state at an appropriate time, from a process running the old version of the software to a process running its new version. The user is responsible for developing, compiling, linking, and debugging both the versions of the program. They must also be linked with a run-time library supplied with the system. Development of the new version is assumed to be done o-line. That is, it does not form a part of the on-line replacement system. As discussed in the previous section, the set of functions being changed must be complete for the change to be valid. Since the system can not interpret the semantics of programs, the checks for completeness cannot be performed by the system. We assume that the completeness and correctness of the change has been veried by the user. However, the system does make sure that the change is installed at the right time such that the on-line change is valid. The major modules of the system are shown in gure 1. The system presents a modication shell to the user. This shell accepts some commands from the user and executes them. All commands related to on-line replacement go through this shell. The commands include those for running a program, replacing it with a new version etc. The list of the commands along with a summary of their functions is given in gure 2. The run module contains routines for running a user program and the replace module 6

7 Run Modication Shell J JJ J JJ Symbol Table J * HHY H JJ H H H H J H H JJ H H Process Handling??????? Run-time Library - Ordinary call - Interprocess call using ptrace Figure 1: Major Modules of the system 7

8 Command Function cd dir Change working directory to \dir". help Print this message. kill Kill the currently running process. quit Exit the modication shell. re new-prog routines [init] Replace the currently running program with \new-prog", functions to be changed specied in le \routines" and \init" as the initialization routine. run prog [arg1...] Run program \prog". tty [tty-name] Set I/O terminal to \tty-name".! cmd Shell escape. Figure 2: Commands of the Modication Shell contains routines to replace the currently running program with a new version. The executable le generated by the linker contains symbol table information for the program. The symbol table handling module contains routines to read this information from the le and store it in the form of an internal table. It also contains routines to search the symbol table etc. The symbol table of the program is required to nd the starting addresses of routines. These addresses are required to check if the stack contains any routine to be changed. These are also required later during actual state transfer so that the program counter and the return addresses on the stack can be mapped to their new values. The run module as well as the replace module create new processes. These processes run as child processes of the modication shell, and are managed by the process handling module. The process handling module controls the two processes by means of the ptrace system call [18]. The ptrace call allows a parent process to inspect or modify the address space and machine registers of its child. A running child process can be stopped by sending it a signal. The parent can resume the stopped child at any address. This mechanism is used to inspect the state of the process running the rst version to determine if state transfer can be done consistently and for actually performing the state transfer. It is also used to make a child process call some run-time library routine. To transfer state, the process running the rst version is made to call a library routine 1 which stores the limits of data and stack addresses in variables whose names are known to the replacement system. This is necessary because the user program may dynamically 1 This routine is linked with the user program and its address is obtained from the symbol table. 8

9 alter these limits. The system reads these values and writes them onto the corresponding variables of the process running the new version. The new process is then made to call a library routine which expands the data and stack space to the limits specied by these values. The replace module then copies the data and stack of the rst process onto the second. The machine registers are copied next. In the case of the program counter, a mapping needs to be made since the starting address of the currently executing routine might have changed. This is done by rst nding which routine is currently executing and what is the oset of the currently executing instruction from the starting address of this routine. To do this, the value of the program counter is compared with the addresses of the various routines as given by the symbol table which is kept sorted on the address. The new starting address of the routine is then found out from the symbol table for the new version of the program and this is added to the oset to get the new value for the program counter. A similar procedure is carried out for all the return addresses on the stack. After the state transfer is over, the old process is killed and the new one is continued. Implementation The system has been implemented on a Sun 3/60 workstation running SunOS. This section describes some of the implementation issues. Maintaining Consistency of Pointers When data is copied from the old to the new version, it is necessary to preserve the consistency of pointers. Our design ensures this in a very simple way. On MC68020 and other architectures using segment based addressing, the rst virtual data address of a process is always on a segment boundary after the text. We assume that the text in the two versions occupies the same number of segments 2. The shell checks if this condition holds and gives an error message if it does not. We also assume that no extra global or static variables have been added in the new version 3. Under these two assumptions, except for addresses of local variables of changed functions, the address of any data object remains invariant across the two versions. Since the change is installed at a time when no changed functions are on the stack, all pointers into data point at the right places after the change. Addresses of the 2 This is a reasonable assumption since the segment size is typically quite large (2MB in MC68020). 3 The system does provide a way to add new global data in an indirect manner. This is discussed later. 9

10 various routines may, however, change across versions and our system does not guarantee the consistency of pointers into text. Deciding when to Transfer State The criteria for deciding when to transfer state is based on the proposition given earlier. We assume that the change specied by the user is complete and if not, the user is willing to accept partially consistent results. For valid on-line replacement, the system has to ensure that the state is transferred at a time when none of the routines are on the stack. To check if state can be transferred at some point in time, the shell unravels the run time stack of the process running the older version of the user program to nd all the return addresses on the stack. These addresses and the value of the program counter are compared with addresses of various routines stored in the symbol table to determine the set of routines which are on the run-time stack. Immediately after the new process has been created and its symbol table built, the system rst checks if state transfer is possible. If state transfer is not possible at the time of the rst check, then the shell nds the lowermost frame on the stack which corresponds to a routine to be changed. The return address from this frame is modied to the address of an illegal instruction which is a part of the library linked with the user program. The original return address is saved in a variable. The user process is then continued. When the last routine on the stack which is to be changed returns, the process incurs an illegal instruction trap and the shell which has been waiting for this event to occur is notied. At this point in time, the stack is guaranteed to contain no routines which are to be changed. State transfer takes place at this time. Note that if a program receives an illegal instruction trap due to some other reason, state transfer gets initiated at a wrong instance in time. However, for programs compiled by a correct compiler, this can never happen. Handling Open Files When the state transfer takes place, the user program will typically have some les open for input and output. The same les must be opened for the process running the second version at the same osets for le I/O to work correctly. The shell process has no means of knowing which les a child process has opened. The run-time library of the system contains special versions of the open and close routines which do some book keeping also along with their normal functions. These versions have to be linked with the user program instead of the 10

11 normal C library ones. The special version of the open routine adds an entry consisting of le name and mode of opening (read, write, append etc.) in an array which is indexed by the le descriptors. At the time of state transfer, before copying the data of the old to the new process, the shell makes the old process execute a library routine which stores the current le osets of all open les in their respective entries in this array. When the data space is copied, this array also gets copied to the process running the new version. The shell then makes the new process call a library routine which opens les whose names are in this array with the specied opening modes and sets the current le osets to their respective values. The order of opening the les is such that the le descriptors are preserved. This ensures correct le I/O after the modication has been done. Handling Changes in Return Value and Parameter Format Frequently in programs, the parameter format and the type of the return value of a function also have to be changed. For example, consider a sort routine which sorts integers and which is required to be changed to a polymorphic sort routine so that other types of data can now be sorted. Assume further that a routine f called sort in the old version of the program. Now the polymorphic sort routine expects more parameters than f provides it. There are two possible ways to achieve modication without loss of consistency in such a scenario. One way is to simply write a new version of f which calls sort with the parameters that its new version expects and inform the shell that f has also changed across versions. The other way to do this is to write an interprocedure[14] called sort which is called with the old parameter format, maps them to the new format and then calls the polymorphic sort routine 4. Writing an interprocedure causes an extra overhead each time it is called. But the shell will have to wait for more time before state can be transferred, if f is modied. Further, if f represents the main loop of the program, then it will get o the run time stack only near the completion of execution of the program, thereby making on-line modication meaningless. It is therefore left to the user to decide which scheme he wants to use in case either the parameter or the return value format of a procedure is to be changed. 4 This routine must not be named sort. 11

12 Initialization Routine The programmer can provide an initialization routine in the new version of the program which will be called by the system at the time of the change. This routine can be used for data restructuring. For example, consider a program having functions which implement a stack using an array. If the new versions of these routines implement a stack using a linked list, then at the time of change, the stack must be \restructured" i.e. a linked list containing the values currently in the stack must be built. This can be done by the initialization routine. The initialization routine can also be used for other purposes. For example, many programs use an array containing pointers to functions and the array is unchanged during the execution of the program. In such a situation, the initialization routine can contain code to reinitialize these pointers since the system does not support automatic mapping of pointers to functions. Adding and Deleting Functions The capability to add new functions in a new version of a program is important for functional enhancement of the program. Deleting unused functions may be necessary because of space considerations. In our system no restrictions are imposed on adding and deleting functions. Adding and deleting functions is treated as an integral part of program modication, and no special actions are needed for this purpose. Furthermore, no dummy versions of functions being added or deleted are required in either version of the program. If a function is added or deleted, it need not appear in the change specication le as explained in an earlier section. However, if a function is deleted, all its callers obviously have to be modied and hence must be included in the change specication le. Similarly, if a new function is added, all the functions which call it in the new version have to be modied and included in the change specication. Adding and Deleting Global Data As explained earlier, any change in global variables of the program may destroy the consistency of pointers (local variables pose no such problems and can be added and deleted freely.) But new versions may require new data structures which may also need to be initialized with state information acquired so far. Our system provides the exibility to add new global data, though in an indirect manner. To add new data, the original program must 12

13 declare some extra pointer variables which are not used in the rst version. The initialization routine must have code which allocates space using malloc or calloc, initializes this space and places a pointer to it in one of these pointer variables which are unused in the rst version of the program. Since the initialization routine is called by the system after the data has been copied to the new process, it can use the values of other global variables to initialize the space allocated. The area can then be accessed in the new version through the pointer. The main drawback of this scheme is that it requires the programmer to declare some extra pointer variables in the rst version of the program so that new data can be added in future versions. Furthermore, when variables are added in the new version, they can not be given meaningful names. Though not very elegant, this scheme will suce for changes that require new data sparingly. Global data deletion is not allowed in our system, as it will destroy the consistency of pointers and other addresses. So, any data that becomes redundant in the new version still must be kept in the new version. Note that this requires careful handling of string constants, as the current C compilers typically treat string constants as global data for the purposes of memory allocation (i.e. they are assigned memory in the data segment of the process, rather than on the stack). If string constants within a function are treated as local variables (as, for example, is done in Pascal), this problem will cease to exist. For the existing C compilers, utility programs can easily be written to check if deletion of functions has inadvertently deleted any string constants or not. Another Approach to Adding Global Data Another scheme for adding data, which is supported in our system and which addresses some of the problems of the above approach, is by declaring an array which is unused in the rst version. All new variables in the second version are \assigned" addresses overlapping with the address range of this unused array, provided the total memory needed for the new variables is less than the size of the array. This scheme has the advantage that new variables can be accessed directly rather than through a pointer, as is done in the previous approach. Also, new variables can be given meaningful names. This scheme requires a translator to generate code for the new variables, to be linked with the second version, that \assigns" memory to variables from this \reserved" area. A translator for this purpose, though not yet implemented, can easily be written. 13

14 Other Restrictions The system imposes some restrictions on user programs. The rst restriction is that the change being made must be complete. In addition, the system imposes restrictions on the use of system calls by the user program. This is because besides the data and stack, a process has some other state information also which is kept in the kernel. Since a user-level implementation such as ours can not modify this information, the user program is prohibited from making system calls which modify such information. Most of these calls can be allowed if special versions for the system calls are written which store this information in some user variables before making the system call. The value of these variables will be copied to the new process at the time of state transfer. The new process can then be made to call a library routine which makes appropriate system calls to modify the kernel information in the same way as the old process. At present, this has been done only for read, write, open and close system calls as explained in an earlier section. This approach will not work in certain cases. For example, if the user program creates a child process and is then replaced by a new version, the new process running the second version will bear no relationship to the child process. However, these restriction can easily be overcome in a kernel implementation of the system. Instead of copying state from one process to another, code of a process itself can be modied in such an implementation and the replace operation can be implemented as a system call. An Example Client-server type of interaction is commonly used in computer systems. In this interaction model, there is a server process which performs certain tasks on request from the clients. The server is typically a non-terminating process while the clients run for short durations. In a client-server system, installing a new version of the server in the traditional manner will imply denial of service to all the clients for the duration of the installation. This can be avoided by on-line version change. Let us consider a simple print server that, on getting a command from the client, formats a le for printing on a particular type of printer and then prints it on the printer. We will use this example to illustrate how a new version of the server can be installed on-line. For simplicity, in the example the client-server communication is done through a named pipe [18] 14

15 char *extra1, *extra2, *extra3 ; /* Some extra pointer variables being declared for future use */ main() f char infile[maxfilenamelen] ; char outfile[maxfilenamelen] ; FILE *fp ; g Create command pipe fp ; for (;;) f read command(fp,infile,outfile) ; format(infile, outfile) ; print(outfile) ; g read command(fp,infile,outfile) FILE *fp ; char *infile ; char *outfile ; f char cmd[5] ; g fscanf(fp,"%s %s", cmd, infile) ; strcpy(outfile,"/tmp/server") ; Figure 3: Print server main loop (in an actual implementation, it is often done through Unix Sockets). In the rst version of the program, the server accepts only one command from the client on the pipe which is of the form: fp lename. On receiving the command the server formats the le lename, keeping the formatted output in a temporary le, and then prints this temporary le. If the executable code of the server program is in the le server, then the server has to be started through the modication shell, by giving the command run server [params]. The overall structure of parts of the server is given in gure 3. Note that variables extra1, extra2, extra3 have been declared, though not used in the server. These are to support addition of global data, if needed. In the second version, the client can give the server another command of the form: fpo 15

16 read command(fp,infile,outfile) FILE *fp ; char *infile ; char *outfile ; f char cmd[5] ; g fscanf(fp,"%s %s", cmd, infile) ; if (!strcmp(extra1,cmd)) fscanf(fp,extra2,outfile) ; else sprintf(outfile,"/tmp/server") ; Figure 4: Version 2 of read command function inle outle. On receiving this command the server formats and prints inle and also leaves a copy of the formatted le in outle. Clearly, for this version of the server the routine read command has to be modied. The formatting and printing routines will remain the same. The new version of the read command function is given in gure 4. In this new version, if fpo command is given, the read command function assigns to outle, the name of the le specied in the command, otherwise the temporary le in the /tmp area is assigned, as in the rst version. The user (the person who will install the new version) has to specify the change conguration le and the initialization routine for doing an on-line version change. Since only the read command function has been modied, the change conguration le just contains: read command: The initialization routine is necessary due to the use of extra variables. The initialization routine init change initializes the value of these variables, and is shown in gure 5. The use of this routine by the system is explained earlier. To transfer control properly, the init change routine calls a system provided cause trap function before exiting. If the executable version of the new server program is kept in the le server.new and the, the change conguration le is named change cong, then the new version is installed by giving the command re server.new change cong init change: 16

17 init change() f extra1 = malloc(4*sizeof(char)) ; extra2 = malloc(3*sizeof(char)) ; extra1[0] = 'f' ; extra1[1] = 'p' ; extra1[2] = 'o' ; extra1[3] = '\0' ; extra2[0] = '%' ; extra2[1] = 's' ; extra2[2] = '\0' ; cause trap() ; g System Performance Figure 5: Change initialization routine for print server We have conducted some experiments to determine the overhead incurred due to on-line replacement. The overhead can be divided into two parts - one is the overhead during normal execution when some extra activities are performed to help the replacement when required. The other is the overhead that is incurred during replacement. In our experiments, we found that the overhead during normal execution is minimal. A program executed through our modication shell (but with no modication done) takes approximately the same time as it does if it were executed through the Unix Shell. This is to be expected since minimal bookkeeping activities are being performed during normal execution. The overhead during the actual replacement comes largely due to the transfer of state information, changing the addresses, and searching the stack. All of these depend on the program and the size of the stack. In our experiments we found the overhead due to these to be very small. For the example given in the previous section, where the function read command was replaced with a new version, we found that on a moderately loaded Sun 3/60 system, the change takes about 200 ms (CPU time). To test the eect of on-line version change on the performance of a running software, another experiment was conducted along the lines of the experiment described in reference [14]. The server code was modied to send a message to a performance monitoring program after processing each request received. The performance monitoring program records the 17

18 number of messages received every second. The server was then run through the modication shell and heavily loaded by running a client which continuously sends it requests. The change to the second version of the server was then made at a random time and the performance of the system during the change was observed. The following was observed. Rate of performing requests before the change Duration of change Rate of performing requests during the 2 second interval containing the change 3.83 per second 1.04 seconds 1.5 per second The change duration of 1.04 seconds was spread over two one second intervals. During these 2 seconds, the number of requests processed was found to be 1 and 2 respectively. This clearly shows that the installation of the change did not cause a signicant deterioration in the performance of the server. The rate of performing requests after the change, may in general, increase or decrease and will depend on the dierence between the old and the new versions. In this case, however, it remained the same, as there was only a minor dierence between the two versions. Conclusion It is now known that a software undergoes many changes during its life time. Changes take place to remove latent errors that are detected during operation, or to enhance the system. In either case, a software in operation has to be replaced by a new version. The most common approach to performing this version change is to shut down the system and then install the new change. This necessitates a sometimes unacceptable delay during which service is denied to the users of the software. In this paper we have considered the problem of on-line version change, in which the version is changed while the software is executing, without shutting down the system. We have dened what it means for on-line replacement to be valid and have developed conditions that must be satised by the change for performing a valid on-line replacement. We have also described a system that allows version change for C programs. The approach followed by our system is to create a new process with the new version. When the conditions 18

19 for valid replacement are met, the state is transferred from the process running the old version to the process running the new version, and then the process for the old version is killed. The system can handle a wide variety of C programs, though it does impose some restrictions. The overhead of performing this replacement is very small. Though currently implemented on a single node system, our system can easily be extended for on-line modication of a distributed program communicating via the remote procedure call (RPC) [19, 20] mechanism. RPC supports a client-server type of interaction (similar to our chosen example). In a RPC implementation, typically the client and the server are two independent processes executing on dierent machines. If only one of them needs to be changed, then the change is like the change in a single process system, and nothing extra needs to be done. If both the client and the server are to be changed, then the server must be modied before the client so that a new version of the client does not send any requests to the old version of the server, which may be unable to accept requests from new clients. To enforce this, the client update must wait till the server update is nished. This information can be given by the updating system running on the server site to the updating system running on the client side. To handle the case of an old version of the client calling a newer version of the server, interprocedures can be used, as was done for handling the change in return value and parameter format in the single process case. More work needs to be done to investigate the possibility of making on-line changes to distributed programs using more exible methods of inter-process communication such as message passing. References [1] E. H. Berso. \Elements of software conguration management". IEEE Trans. on Software Engg., 10(1):79{87, [2] W. F. Tichy. \Design, implementation and evaluation of a revision control system". In Proc. 6th Int. Conf. Software Engg., pages 58{67, Tokyo, [3] J. Magee, J. Kramer, and M. Sloman. \Constructing distributed systems in Conic". IEEE Trans. on Software Engg., 15:663{675, June [4] D. Perry. \The Inscape environment". In Proc. 11th Int. Conf. on Software Engg., pages 2{12,

20 [5] J. Purtillo. \The polylith software bus". Tech. report no. 2469, Univ. of Maryland, Also to appear in ACM Transactions on Programming Languages and Systems. [6] C. Hofmeister, E. White, and J. Purtillo. \Surgeon: a package for dynamically recon- gurable distributed applications". In Proc. IEEE International Conference on Congurable Distributed Systems, March [7] J. Purtillo and C. Hofmeister. \Dynamic reconguration of distributed programs". In IEEE International Conference on Distributed Computing Systems, pages 560{571, May [8] J. Kramer and J. Magee. \Dynamic conguration for distributed systems". IEEE Trans. on Software Engg., SE-11(4):424{436, April [9] J. Kramer and J. Magee. \The evolving philosophers problem: dynamic change management". IEEE Trans. on Software Engg., 16(11):1293{1306, November [10] M. R. Barbacci, D. L. Doubleday, and C. B. Weinstock. \Application-level programming". In IEEE International Conference on Distributed Computing Systems, pages 458{465, [11] R. S. Fabry. \How to design systems in which modules can be changed on the y". In Proc. 2nd Int. Conf. Software Engg., [12] H. Goullon, R. Isle, and K. Lohr. \Dynamic restructuring in an experimental operating system". IEEE Trans. Software Engg., SE-4(4), July [13] I. Lee. \DYMOS: a dynamic modication system". PhD thesis, University of Wisconsin, [14] M. E. Segal and O. Frieder. \Dynamic program updating: a software maintenance technique for minimizing software downtime". Software Maintenance: Research and Practice, 1(1):59{79, September [15] O. Frieder and M. E. Segal. \On dynamically updating a computer program: from concept to prototype". J. System Software, 14(2):111{128, September

21 [16] M. E. Segal and O. Frieder. \Dynamically updating distributed software: supporting change in uncertain and mistrustful environments". In Proc. IEEE Conference on Software Maintenance, October [17] E. W. Dijkstra. \Guarded commands, non-determinism and formal derivation of programs". Communications of the ACM, 18(8):453{457, [18] Sun Microsystems Inc., Mountain View, CA. \Sun OS reference manual", [19] A. Birell and B. Nelson. \Implementing remote procedure calls". ACM Trans. on Computer Systems, 2(1), February [20] A. D. Birell. \Secure communication using remote procedure calls. ACM Trans. on Computer Systems, 3(1), February