Mumbai University > Information Technology > Sem 6 > Distributed System

Marks: 10 Marks

Year: May 2016

Distributed systems are constructed on a heterogeneous collection of platforms, each having their own operating system and machine architecture.

Migration in such systems requires that each platform is supported, that is, that the code segment can be executed on each platform, perhaps after recompiling the original source.

Problems can be somewhat alleviated when dealing only with weak mobility.In that case, there is basically no runtime information that needs to be transferred between machines, so that it suffices to compile the source code, but generate different code segments, one for each potential target platform.

In the case of strong mobility, the major problem that needs to be solved is the transfer of the execution segment. The problem is that this segment is highly dependent on the platform on which the process is being executed. In fact, only when the target machine has the same architecture and is running exactly the same operating system, is it possible to migrate the execution segment without having to alter it.

The important observation is that if we can avoid having execution depend on platform-specific data, it would be much easier to transfer the segment to a different machine, and resume execution there.

A solution that works for procedural languages such as C and Java is shown in Fig. and works as follows.

• Code migration is restricted to specific points in the execution of a program. In particular, migration can take place only when a next subroutine is called. A subroutine is a function in C, a method in Java, and so on.
• The runtime system maintains its own copy of the program stack, but in a machine-independent way. We refer to this copy as the migration stack. The migration stack is updated when a subroutine is called, or when execution returns from a subroutine.
• When a subroutine is called, the runtime system marshals the data that have been pushed onto the stack since the last call. These data represent values of local variables, along with parameter values for the newly called subroutine.

• The marshaled data are then pushed onto the migration stack, along with an identifier for the called subroutine. In addition, the address where execution should continue when the caller returns from the subroutine is pushed in the form of a jump label onto the migration stack as well.

  

  Fig :The principle of maintaining a migration stack to support migration of an execution segment in a heterogeneous environment.

• If code migration takes place at the point where a subroutine is called, the runtime system first marshals all global program-specific data forming part of the execution segment.
• Machine-specific data are ignored, as well as the current stack. The marshaled data are transferred to the destination, along with the migration stack. In addition, the destination loads the appropriate code segment containing the binaries fit for its machine architecture and operating system.
• The marshaled data belonging to the execution segment are unmarshaled, and a new runtime stack is constructed by unmarshaling the migration stack. Execution can then be resumed by simply entering the subroutine that was called at the original site.