Virtualization and Code Migration

Motivation for Code Migration

• Load sharing in distributed systems
• Long-running process can be migrated to idle processors
• Client-server systems
• Code for data entry shipped to client systems
• If large quantities of data need to be processed, it is better to ship the data processing component to the client
• Dynamically configurable client software
• More flexibility, easier maintenance and upgrade of client software
• Enterprise and "Desktop Grids"
• Computationally-intensive tasks shipped to idle PCs around the network

Models for Code Migration

• A process has three segments
• Code segment
• Set of instructions making the problem
• Execution segment
• Private data, stack, PC, registers
• Resource segment
• Reference to external resources such as files, printers, devices etc
• Weak vs Strong Mobility
• Weak mobility
• Only code segment + initialization data migrated
• e.g., Java Applets
• Strong mobility
• Code segment + Execution segment
• Send-initiated vs. receiver-initiated migration
• Receiver-initiated is much easier considering security

Migration and Local Resources

• Process-to-resource bindings make code migration difficult
• Three types of processor to resource bindings
• Binding by identifier
• When a process refers to a resource by its identifier
• e.g., URL, IP address, local communication endpoint (socket)
• Binding by value
• Weaker form of binding when only the value of a resource is needed
• e.g., when a program replies on standard language libraries
• Binding by type
• Weakest form of binding when a process indicates the type of a resource
• e.g., a printer