Migration

Two types of migration:

• Virtual Machine migration (ala xen migrate)
• Active Object/Class migration

both of which can be achived with contiunation object support in the VM, and alloing the continuation object to be serializable/unserializable.

However, resource management needs to be very carefully considered in this.

Begin able to pack up an entire VM in it’s state and move to another machien would be pretty useful. Although we need to consider a few thigns:

• open files
• shared memory
• sockets (database, etc)
• other resources and modules
• JIT architecture dependent code

included files would need to be moved across as well - or perhaps jsut the BytePack which contains all included files.

It would be nice to be able to support migration with HTTP clients somehow if we could issue a HTTP 302 with Location: header pointing to the bnew VM container *somehow*.

– Not sure how useful any of this would actually be in the real world other than for queuing jobs that can be processed asynchronously, and eevn then loosing database transactions makes than potentially not to useful.

 
/*
 * completely random thoughts on how to handle migration:
 */
 
class MyApplication implements IMigratable
{
 
  void somefunction()
  {
    VM::getInstance()->migrate('1.2.3.4');
  }
 
  void onJustAboutToMigrate()
  {
  }
 
  void onMigrationComplete()
  {
    // need to reconnect databases, etc.
  }
 
}

Internally, to migrate a VM, we need to:

• Finish any lazy parsing
• Pause VM::exec()
• Serialize Stack
• Serialize BytePack
• Send serialized BytePack to remote sandbox
• De-serialize BytePack into sandbox
• De-serialize stack
• continue execution