jms@close.columbia.edu (Jonathan M. Smith) (05/13/88)
>From kasper@csli.stanford.edu Fri May 13 11:02 EDT 1988 >Subject: Migrating programs > >Thanks for you paper. Not only is it a good survey, but a good introduction >too. However there are one place where you toss out a undocumented goddie. >on p2, second column, first dot, you talk about remote databases, but you >do not refere to any work there - is this a private idea of yours, or have >any work been done to document this use of migrating processes. > >Also you can considder PostScript to be program migration (Or NeWS for >that matter) but ofcause it depends on what we define prog. migr. to be. > >--Kasper > >Ps. I have posed my results to comp.os.research > My reply may be of interest to comp.os.research readers: Kasper: Well, the database stuff is really a private thought (after a discussion with Prof. Gerald Q. Maguire, Jr.); I wrote it down when I was looking for a thesis topic two years ago, and it still seems like an interesting idea to me. It's not something I've seen done; most of the migration mechanisms have been biased towards "processing" load balancing rather than I/O load-balancing. This may be a an artifact of the systems architectures we've seen process migartion built upon. The XOS paper I cited points out the sort of load balancing one could accomplish in a tree; if you're interested in pursuing this, I'd like to talk with you. You see, in a tree, the cost of data access varies by a *known* quantity with separation distance, i.e. log N for N nodes. It's probably considerably more difficult to determine such stuff dynamically in a distributed system. There are some interesting timing figures in the V system paper, and Zayas' paper gives some size statistics. Are you a graduate student? There might be a good thesis there! On the PostScript; we have some thoughts there too. Interpreters look like a good way to do things; see the paper: %T A Programmable Interface Language for Heterogeneous Distributed Systems %A Joseph R. Falcone %J ACM Transactions on Computer Systems %V 5 %N 4 %D November 1987 %P 330-351 %X Falcone describes NCL, essentially a LISP interpreter which provides a virtual machine interface to heterogeneous systems in a client/server relation. The client creates an environment it can use to solve its problems using primitives offered by the server's implementation of NCL. for a treatment. The idea is that an interpreted program (e.g., Lisp, PostScript, or NCL) can be executed anywhere where there's an interpreter, thus isolating heterogeneity to the implementation of the interpreter. This approach is similar to that taken by the people at U. Washington; see the March 1988 CACM for a description of their approach. Regards, -Jonathan