discussion: limits of objects

[Gary D. Duzan]

In Message <9412070114.AA22601@clipper.ens.fr> ,
   rideau@clipper.ens.fr (Francois-Rene Rideau) wrote:

=>So, as of inter-code communication, the *big* problem with our
=>migrating objects (and we know that in a persistent, distributed,
=>system, they will migrate a lot, and even the seldom migrating will
=>migrate between backup/persistent store and RAM), is what are the
=>limits of an object ?
=>
=>When object A uses objects X,Y,Z,T, we may want to migrate object
=>A but not objects X Y Z T (unless needed). Then, how to find the
=>limits ? How can it be compatible with our need for efficiency (i.e.
=>inline interactions between A,X,Y,Z,T when possible) ?

   Well, if one object can directly manipulate the state of another,
then the problem becomes an exercise in distributed shared memory.
On the other hand, if objects have controlled interfaces, a migrated
object can leave a stub behind to handle things. For example, an
object migrated to disk would leave a stub behind that calls the
object swapper object to load the object back into RAM then pass
the call to the restored object. An object migrated to another
system can forward the calls via network handler objects to the
new system. A possible optimization for objects that move a lot
would be a smart stub that could detect when it is being accessed
from another stub and return a copy of itself to replace the calling
stub. (i.e. A->B->C->D. Stub C sees that B is a stub and sends a
message 'use D instead' back to B. From then on we have A->B->D.)
For the local case a write to another object's state becomes a
call-write-return. The performace implications are left as an
exercise for the reader. :-)

                                      Gary D. Duzan
                         Humble Practitioner of the Computer Arts