[clug] Random Thought: support for Hot-code swap in the kernel

[jm]

Robert Edwards wrote:
>
> So, there is a distinct difference between migrating from one _version_
> of a given app to another and moving an _instance_ of an app from one VM
> to another. Most VMs can support moving instances of any app from one VM
> to another, sockets and all.

Which is why I ignored it after initally raising the idea. related but 
separate problems.
> Migrating from one _version_ of an arbitrary app to another requires
> complete co-operation from the app itself (ie. the app programmers must
> have allowed for this). There is simply no way that the OS can make
> assumptions about things like memory structures not changing between
> versions to make this, for all intents and purposes, impossible.
> Serialising the data won't help if the new version has new fields in
> it's structures.

True. The different versions must co-operate. Either the data structures 
must be identical or you need to have the new version understand the old 
versions data structures and migrate these across. As I understand it 
this is what occurs in the languages/VMs that support this. A special 
code_change() function is called by the programmer or the library with 
the old data structure and some additional information. This function is 
then expected to return the new data structure for use with the new 
version of the app. (excuse the glossing over of detail here.)
> Once the app programmers design for live migration, then the choice of
> language can be important but most things can be dealt with through
> clever design.
Agreed I couldn't imagine the programmer changing languages between 
versions and doing this. It may also be more difficult for 
non-functional languages or if you make extensive use of threads, but 
not impossible.

I suppose the central thought is can the level of the VM be remove from 
the equation and still have hot-code swap possible.

Jeff.