Distributed software applications are widely used in both in 
industrial and research environments. A distributed software 
application consists of a set of components and an 
associated configuration that maps the components to 
processing elements and defines bindings between them, 
indicating communication channels. There are many different 
tools and techniques for describing and supporting static 
configurations of distributed applications. 

Just as with the previous example, we need to consider both
when a reconfiguration is legal and what changes need to be made.  
Reconfiguration can only take place when 
a consistent snapshot of the overall grid is available. 
This means that at reconfiguration time the processes must 
synchronize at the same spot on the same iteration before
the changes are legal. 
Once synchronization at this consistant state as been achieved,
any new processes need to be started with communication channels
bound to their neighbors, the new
partitioning of the data needs to be computed, the data needs to be
moved to correspond to this new partitioning, any variables related to
the data set size need to be updated, and finally, any extra processes 
need to be removed.

While we found using an annotation-based approach to describing the 
adaptations to be quite useful, unrestricted use of this or any other
adaptation framework can cause serious problems that
are non-trivial to detect.  When a program variable is modified at
adaptation, it is important to consider whether any other program variables
might potentially have depended on that variable.

With this framework, component-level adaptation 
behaves as follows.  When an application reconfiguration
needs a component to adapt some part of its local state, the component is 
sent a signal. Adaptation does not happen immediately; instead, the component
continues executing until it reaches the next adaptation point in the program.

It is possible for a variable to be classified differently at different 
points; however, at a given point in the source code, a variable is always 
exactly one of these three types.    
f the associated slice for a variable does not contain
any of the change code, the variable is conserved and we know that its value
will be correct after an adaptation.
If the associated slice for a variable contains only change code, the
variable is adaptable.  By definition, variables local to a non-main procedure
cannot be adaptable because if the slice includes change code,

In addition to analysis, we have developed ways to automatically transform 
annotated source code so that it can work within our reconfiguration 
environment. Adaptation points in the main program require minimal 
transformations.  First we need to save information
about the location of the current adaptation point. 
Then, control needs to be transferred to the 
change code so that it can be executed.  Finally, control is
transferred back to the line after the adaptation point where since   
the component's state has been adapted, normal execution can resume.

Adaptation points in non-main functions require more sophisticated
techniques.  One option would be to copy the change code to these
points; however, this will only work if the adaptable variables are all
global.  What is really needed is a way to transfer control to the main 
and back, while updating any adaptable information on the stack.

The approach we take for dealing correctly with both the control flow
and with adaptative parameters
is based on Hofmeister's technique for abstractly capturing 
and restoring the runtime stack for
run-time process migration.  This source-code based method, discussed
in the next section,
builds an abstract representation of a runtime-stack and its contents for
the process to be migrated and uses this abstract representation to
rebuild the process on the new machine.