The Tunes Migration Subproject


Contents of the Migration Subproject

Here are the current contents of the Distribution project:
  • Firstly, the goals of the subproject
  • The unit of migration is the module
  • Migration involves communication as a mechanism
  • The scheduling is done according to heuristics
  • These heuristics are computed according to dynamic measurements.
  • Of course, there are many difficulties on which we have to focus.
  • Still no implementation code.


    Goals for the Migration subproject

    The goal of this Subproject is a find, study, and implement existing or new techniques that allow to take full advantage of distribution in a computing system, through the concept of dynamic migration of fine-grained objects.

    Migration is when an objects gets abstracted from its current context and applied to another context. The system shall automatically do such operations to automatically dispatch objects accross the distributed system, so as to improve performance, by reducing total resources spent (including time), while respecting the human user's constraints.

    Migration encompasses swapping objects to disk, upgrading modules, users logging on different machines, dettaching and reattaching objects to different I/O devices/terminals/etc.
    All the migration scheduling should be under full user control, be it direct, indirect, remote, or purely potential.

    It is a very important feature in the Tunes system, that no other known system do provide at all (but as specific swapping of raw chunks of memory).



    Modules

  • see the HLL page...
  • see the LLL page...
  • portability accross different architecture
  • local (real-time ?) and distributed higher-order GC
  • insist on fine grain allowing better, more efficient distribution
  • annotations (typing is done through them)


    Distribution Difficulties

  • Design
  • Modules
    • In a recursive objects with variables that gets migrated, how delimit the object ? Shall variables be replaced by copied ? Shall copies be share ? Which becomes what ?
  • Communication
  • We must have some parametrizable security here; but basically, an external communication line should never be trusted 100%
  • We must have some ways to identify remote objects in a GC compatible way.
  • We must be careful about
  • Heuristics
    • When must we migrate an object ?
    • Where to migrate the object ?
    • How to minimize total load ?
    • How to still satisfy the current user ?
    • How have active annotations not working on the annotated object's resources, but on its own ?
    • When archiving the state of an object, what to do with links to remote objects ? Keeping the link may mean garbage will be kept; losing the link may mean the archive will be useless; copying the remote object may mean lot of copying. Policy depends on the level of trust between those objects, on the size of the objects, on the available space to store, etc.


    To Do on this page

  • Find all Migration topics.
  • Find all implementational problems.
  • Make first proposals.
  • Divide into subfiles.
  • Open a "distributed GC" subproject ?
  • Add pointers to Sony, Shapiro, etc


    Back to the Tunes Home page.


    Page Maintainer:
    Faré -- rideau@clipper.ens.fr