Análisis y determinaciones

In the 1980’s through to the late 1990’s, much work was done on process migration in desktop computing. Milojicic et al. [69] have surveyed this field and give an overview of the application areas, research and implementations, and present reasons as to why migration never caught on.

In general, the application areas for process migration cover load balancing and distribution, the exploitation of resource locality, resource sharing, fault resilience, systems administra- tion, and mobile computing. These concepts can be summarised by saying that process mi- gration enables applications, either autonomously or with outside direction, to be liberated from their current execution environment for the purposes of efficiency, safety or policy. The survey notes suitable applications areas are those that exhibit parallelism, long lifetimes, and mobility; this is corroborated by Smith et al. [70].

The aforementioned research on process migration covered many different areas and many different systems. The general findings can be summarised in a number of points.

Firstly, migration-capable systems which use message passing are easier to design and im- plement than those that do not, especially in terms of location transparent communication. This is because message passing offers a decoupling of interaction between software entities. This opinion is also expressed by Smith et al. [71]. However, it is noted that this advantage is at the expense of complex communication logic within the runtime. In order to ensure mes- sage delivery after process migration, some approaches use message forwarding; however, this can lead to complex network routing and is not efficient. A more desirable approach is taken by the V kernel [72] (and Xen), where routing information is updated after migration, however the details are not discussed in depth.

Secondly, environmental entanglement is not solved, with all application and user level ap- proaches requiring that any process to be migrated must be isolated. Some of the micro ker- nel approaches, particularly Mach [73], provided distributed shared memory and distributed inter-process communication to mitigate some elements of entanglement, although this can lead to very complex runtimes.

Thirdly, one of the factors which contributed to the lack of success for process migration was complexity within the runtime systems. This is especially true for Mach, where the support for distributed memory management and IPC became very complex.

Other examples included a lack of applications, migration not being required as other tech- nologies (RPC, discussed below) were available and well understood, a lack of wide spread infrastructure support - i.e., Windows did not support migration, and security concerns. The work does suggest ways to address these issues, however these are quite general and based on assumptions about the computing environment and changing trends in comput- ing technology, some of which have only now been realised in terms of mobile computing hardware, and the applications that are executed on them.

Other work on migration focused around modifications to Java to extend the serialisable functionality which was already present; to not only move a component from one location to another, but to enable it to also take its execution state. Generally this work fell into two categories, one which modified the Java VM to support migration [74, 75], and preprocessing of Java code to insert mechanisms to save the state before migration and restore the state after migration [76], the so-called checkpoint-restart approach. The work of Baumann et al. [77] describes another system which provides mobility around Java, but also presents a classification of different types of mobile programming by introducing different levels of mobility: remote execution, weak migration, and strong migration.

Remote execution covers remote produce calls (RPC) and the Java equivalent, remote method invocation (RMI) [78]. This is the ability to invoke a procedure or method on a remote ma- chine. Here a stub piece of code is automatically generated during the compilation process on each machine. Its duty is to abstract over the heterogeneity of different machines as well as handle networking issues such as marshalling. It should be noted that RPC/RMI operates within the semantic space of a single memory region, as opposed to actors which use the shared-nothing semantics to create applications with distinct memory regions. Hence, actors are more naturally suited to distributed applications.

Weak migration is the ability to relocate the code and data but not the process state. Consid- ering an actor system, this means that an actor can be inserted at a remote location, but will start from the beginning of its behaviour. This provides the ability to replace, and relocate an actor. Migration is still possible with this scheme, but requires the actor’s behaviour itself to orchestrate this, using the checkpoint-restart method.

Strong migration refers to the ability to relocate the code, data, and state of a process. Again, considering an actor system, this is the ability to pause an executing actor, save its state, transport it to another machine, and let the actor resume execution as though nothing had happened.