Mobility differs from conventional process migration schemes in two important
aspects:
- Emerald is based on a <#2710#> fine-grain object model<#2710#> rather than
heavyweight processes.
- The unit of distribution is the object.
The units of mobility are thus potentially much smaller for Emerald than
conventional systems. In addition, the mobility concepts are integrated into
the language, allowing the possibility of cooperation and the exchange of
contextual information between compiler and runtime system. This results in
greater efficiency than is available in other systems.
The primitives for mobility in Emerald have already been discussed in section
#emerald#2712>. In addition to the move, fix, unfix, and refix operations, there
is a mechanism for object <#2713#> attachment<#2713#>. If a variable, <#2714#> a<#2714#>, is declared
to be attached to another, <#2715#> b<#2715#>, then moving object denoted by variable <#2716#>
b<#2716#> also causes <#2717#> a<#2717#> (and any object attached to <#2718#> a<#2718#>) to be moved to the
same node. Note that this relation is not symmetric; moving <#2719#> a<#2719#> does not
cause <#2720#> b<#2720#> to move. The importance of attachment can be seen by noting that
in object-based systems one of the largest costs is invocation, particularly
remote invocation. If two objects are known to communicate heavily at some
period of time, then it is possible to attach them, and so ensure that all
communication between them remains local for the relevant period.