Processes: Code Migration

Processes: Code Migration Chapter 3 Will Cameron CSC 8530 Dr. Schragger

Overview • What is Code Migration • What does it offer a distributed system? • Models for Code Migration • Weak Mobility and Strong Mobility • Sender and Receiver Initiated • Migration and Local Resources • Binding Categories • Heterogeneous Migration

Code Migration • “Moving programs between machines with the intention to have those programs be executed at the target” (Tanenbaum and Steen) • Traditionally code migration in distributed systems took place as process migration • The execution status of a program, pending signals, other parts of the environment must be moved as well • Entire process moved from one machine to another • Costly and intricate task, only done for good reason: performance

Why Code Migration? • Overall system performance can be improved if processes are moved from heavily-loaded to lightly-loaded machines • Where ‘load’ is CPU queue length, CPU utilization • Load distribution algorithms played important role • Allocation and redistribution of tasks with respect to a set of processors • In modern DS optimizing computing capacity is less an issue than trying to minimize communication • Migration to a safer environment

Performance • It generally makes sense to process data close to where those data reside (get client server split slide) • Example: Client-server system where the server manages a huge DB • If a client needs to do many db operations involving lots of queries • It may be better to transport part of the client application to the server and send only the results over the network • Otherwise it may be swamped with the transfer of data from the server to client • Example: Migrating parts of the server to the client • Clients need to fill in forms translated into a series database operations • Process the form on the client, sending only the completed form to the server • Reduce large number of small messages across the network • Client perceives better performance while the server spends less time on form processing and communication

Multitiered Architectures (1) • Alternative client-server organizations (a) – (e). 1-29

Parallelism • Code Migration can provide parallelism • But without usual parallel difficulties due to the independence of code copies • Fewer worries concerning the overriding of a shared address space, etc • Examples • Implementing a web search as a small mobile program that moves from site to site • Make several copies of it, send off to different sites to speed search

Flexibility • Traditional Distributed Applications • Partition the application into different parts • Decide in advance what machine each part should be executed • Lead to multi-tiered client-server applications in chapter 1 • If code can move between different machines • Can dynamically configure distributed systems • Example: Server interface to a file system • Client side implementation of file system interface needs to be linked to client application • Thus the software would need to be readily available to the client at the time the client application is developed • Alternative: server provide client implementation when the client binds to the server • Client dynamically downloads the implementation, sets it up, invokes server • Requirements • Protocol for downloading and initializing code is standardized • Downloaded code must be compatible with client machine • Security issue: (bring in Applets, security, etc) • Trusting the downloaded code only implements the advertised interface

Reasons for Migrating Code • The principle of dynamically configuring a client to communicate to a server. The client first fetches the necessary software, and then invokes the server.

Models for Code Migration • Framework of three segments • Code Segment • Contains the set of instructions that make up the program being executed • Resource Segment • References to external resources needed by the process • Files, printers, devices, other processes • Execution (Process) Segment • Store the current execution state of a process • Private data, stack, program counter

Weak Mobility • Transfer only the Code Segment with some initialization data • Program always starts from its initial state • Java applets • Benefit • Simplicity • Just requires portable, executable code for the target • Matters whether the code is merely executed by target process or a new process is created • Applets are simply downloaded and executed in browser space • No need for new process, communication at target • Drawback: target process needs to be protected by malicious or inadvertent code executions • OS solution: create a separate process

Strong Mobility • Execution segment transferred as well • Running process stopped, moved to another machine, resumed • More powerful than weak, much harder to implement • Or Remote Cloning • Yields an exact copy of the original process but on a different machine • Executed in parallel to original • UNIX: fork off a child process onto a remote machine • Benefit: • Model closely resembles existing, but on another machine • Simple way to improve distribution transparency

Models for Code Migration • Alternatives for code migration.

Sender-Initiated migration • Migration initiated at the machine where the code currently resides or being executed • uploading programs to a server: Dist. File System • Sending a search program across the Internet to a Web database server to perform queries • Often requires the client be previously registered and authenticated at that server • Server must know all its clients b/c client will want disk: security

Retriever-Initiated migration • Initiative for code migration taken by the target machine • Java applets • Simpler to implement, client takes initiative, • downloading done anonymously • server not interested in the client’s resources • Code migration to client done just for improving client side performance • Just server memory and network connections need be protected

Migration and Local Resources • This makes code migration difficult, resource segment cannot be simply transferred without being changed • Process reference to a specific TCP port to communicate to another process • When moved to another location, must give up port and request a new one

Binding Categories • Binding by identifier • Not a problem: absolute URL, still valid • FTP server by internet address • Local communication endpoints also binding by identifier • Bind by value • Weaker process-to-resource binding, only the value is needed • Execution not effected if another resource provide the same value • Example: program rely on standard libraries, C, Java • Always available but exact location could differ • Bind by type • Process indicates it only needs a resource of a given type • References to local devices: monitors, printers..

The Resource-to-Machine Bindings • Often need to change the references to resources but cannot affect the kind of process-to-resource binding • Can a reference be changed, depends on whether that resource can be moved and code • Unattached resources can be easily moved, typically data files associated with program to be migrated • A fastened resource can only be moved with relatively high cost • Examples: local databases, complete web sites • In theory not dependent on machine, but infeasible to move • Fixed Resources • Intimately bound to a specific machine or environment • often local devices, local communication endpoint • Establishing global references can be costly

Migration and Local Resources Resource-to machine binding • GR: Global Reference • MV: Move the resource • CP: Copy the value of the resource • RB: Rebind process to locally available resource • Actions to be taken with respect to the references to local resources when migrating code to another machine. Process-to-resource binding

Heterogeneous Migration • Realistic situation in DS • Migration requires that each platform is supported for code segment • Issues • Weak Mobility • No runtime info to transfer, just recompile the source code , but generate different segments, one per platform • Strong mobility • Transfer of the execution segment: PC, registers, stack, etc • Highly dependent on platform • Same OS and architecture • Solution • Only allow code migration at specific execution points: when the next function, method, or subroutine is called (C, Java) • Migration stack • The runtime system maintains a machine independent program stack • Updated when a subroutine is called or when execution returns from one • Identifier for called subroutine • Jump Label pushed as well • The address where execution should continue when the caller returns

Migration in Heterogeneous Systems • The principle of maintaining a migration stack to support migration of an execution segment in a heterogeneous environment 3-15

Heterogeneous Migration • If migration takes place when a subroutine is called • Runtime system marshals all global program-specific data to form execution segment • Machine specific data and current stack ignored • Marshalled data transferred to destination along with the migration stack • Only works if compiler generates code to update the migration stack whenever a subroutine is entered or exited • Generates labels in the caller’s code allowing a return from a subroutine to be implemented as a (machine-independent) jump • Suitable runtime system needed • Virtual Machines • 1970s: Pascal machine independent intermediate code for an abstract virtual machine on many platforms • Did not catch on with other languages: C • 1990s: Scripting Languages and Java • All such systems: • Rely on a virtual machine to directly interpret code (scripting languages • Or interprets intermediate code generated by compiler (Java bytecode) • Drawback: we are stuck with a specific language

Conclusions • Code Migration is an interesting way to improve distributed efficiency, through a sort of multiprograming provided by parallelism • Its various manifestations raise issues of security and process migration which must be addressed • Virtual Machines provide a nice solution to heterogeneous migration issues

Processes: Code Migration