Process migration, was: Re: Extending arithmetic

[Scott Lystig Fritchie]

>>>>> "vd" == Vlad Dumitrescu (EAW) <Vlad.Dumitrescu@REDACTED> writes:

vd> An image that popped up in my mind was that we could send a
vd> "freeze" command to a process and then be able to retrieve the
vd> process heap. It could then be moved to another VM, and the
vd> process could be thawed... it wouldn't notice a thing :-) Maybe
vd> some of this can be included in the gen_ behaviours, but for the
vd> heap retrieval/restoration the runtime will have to cooperate.

ETS tables muck up the works, though it's easy enough to use
ets:tab2file/2 or ets:tab2list/1 to transfer them to the new
location.  If you're relying on a public ETS table, then you get moved
to a node that doesn't have that table (or has one by that name but
different contents), er, well, don't do that.  :-)

Process linking is tricky.  If A is linked to B, and B is migrated
into a process C, then:

* if C is simply linked to B, then when C dies, B will die too.
Hopefully A will not be confused when A receives an EXIT message from
C (which A knows nothing about).

* if the VM has support for this kind of thing, then perhaps the link
from A<->B could be silently moved to A<->C, but if C dies, then the
VM should translate the Pid in C's EXIT message to use B's Pid.

Message passing: it's easy enough to have B forward all messages to
C.  It's extra overhead to do that.  (No, I haven't measured how much,
but I should if I were ever serious about this sort of thing, right?)

If A is aware that B has moved ... well, I haven't thought too hard
about this.  If you're using functions to encapsulate sending all your
messages to B, then A could use its process dictionary (!) to keep
track of which Pids have migrated and what their new Pid ... without
mucking A's source code (much) to keep track of this new state.

I've probably missed a bunch of stuff.  Has anyone actually
implemented this sort of thing?  Lessons learned there would be
interesting.

-Scott