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
–
If code can move between different machines
–
–
–
–
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
•
Can dynamically configure distributed systems
•
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
Example: Server interface to a file system
•
•
•
•
•
–
–
Protocol for downloading and initializing code is standardized
Downloaded code must be compatible with client machine
–
Trusting the downloaded code only implements the advertised interface
Security issue: (bring in Applets, security, etc)
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
–
–
Simplicity
Just requires portable, executable code for the target
• Benefit
• 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
Process-toBy identifier
resource
binding By value
By type
•
•
•
•
•
Unattached
Fastened
Fixed
MV (or GR)
CP ( or MV, GR)
RB (or GR, CP)
GR (or MV)
GR (or CP)
RB (or GR, CP)
GR
GR
RB (or GR)
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.
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
3-15
• The principle of maintaining a migration stack to support migration
of an execution segment in a heterogeneous environment
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