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

Leave a Reply