January 2003

Migration

Migration is about maintaining contracts. There are two main type of contracts, the program contract and the environmental contract. The idea behind migration is to maintain the program contract while satisfying new environmental contracts. Of course contracts are not limited in complexity, and therefore we can not expect a single susinct static contract language to exist.

The best solution, as I see it now, is to define a set of useful contract templates (parametric contracts) for both programs and environments and build a system that can migrate programs inside this limited domain. Hopefully this will reveal a more general and elegant pattern of migration.

Program Contracts

Program contracts are quite common, but complex. Most program contracts are implicit in the semantics of the language used to specify the program (eg GC is required). Here are some examples that are independent of language semantics.

• PRE and POST conditions on methods
• ASSERT statements
• Restrict a variable to a certain domain (or type)

Good migration depends on a language with sufficient semantics to portray the high level intent of the programmer without undue restriction. For example, if a C programmer uses a particular list implementation, does he mean to use the abstract list contract, or it is just a side effect of the specific implementation? The former allows migration to a machine that may have hardware support of lists. The latter may be demanded by a routine that takes advantage of the list implementation in some peculiar way (debugging?) and prohibiting the use of native machine lists. We can see that C is a poor language for migration, and so too for so many other languages where a module's implementation imposes contracts that the module's interface does not.

Environmental Contracts

Here are some environmental contracts that may be are familiar:

• Limit the amount of memory used
• Demand certain minimum speed
• Use a given instruction set
• Use given machine resources
• Use computer X as a backup

Of course, differentiating between program contracts and environmental contracts is just an arbitrary partition of contracts in general. There is no rule that says some of my examples can not be seen as either a program contract or environmental contract. All that matters is that the contracts do not conflict and result in a program that can exist.

Some examples of migration are:

• Have program X run on machine Y
• Have program X run with a minimum memory footprint

Summary

Migration is a large and complicated task. The DBOS design does not addresses these issues to any real depth. Yet KMAL is being designed to allow for mimimal contract specification by using macros and establishing interface contracts. The MSM format is a low level code format where macros are reduced to second order functions. These are not solutions to migration, but allow a possible migration system to hook into the semantics of a program and transform code as required by environmental contracts.

January 2003 - First Draft