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 will be under
full user control, be it direct, indirect, remote, or purely potential.
Migration is a very important feature in the Tunes system,
that no other known system do provide at all
(but in its most primitive, non parametrizable form, swapping raw chunks
of memory between memory and a swap file or partition on harddisk)
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
- We must separate mechanisms and policy.
- When we get at a higher abstraction level, we see
policy is the meta-mechanism,
and the way to choose the policy is the meta-policy, etc.
- We must dynamically balance fine-grain of modules and heaviness of
annotations:
the finest grain the modules, the most adapted the migration,
the heaviest the annotations, the most adapted the migration;
however, the highest the annotation heaviness/module grain size ratio,
the highest the time lost doing administration instead of useful
computations.
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 ?
- We see that the requirements to allow migration are the same as
those to allow garbage collection...
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 provide ways to encode objects so that any computer can understand
what any other sends to him.
However, this shouldn't prevent non-standard computers to communicate
with local encodings more efficient than the standard one for them
(e.g. it would be stupid to force all computers in a local network
to systematically swap the byte order of 32-bit numbers when they
share the opposite endian-ness from the standard one).
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
Open a "distributed GC" subproject ?
Open a subproject about a distributed project manager,
than would help multiple persons on the net
consistently develop documents,
even though propagation time is slower than peak static
development time.
The subproject should be generic enough to allow development
of any kind of documents (not just text), with several policies,
so that it could be used as a replacement for usenet, the WWW,
RCS, ftp mirroring, all alike.
Perhaps contact the Xanadu team, as they've
certainly got much more experience than we do on this subject...
That is, have a subproject about distribution policy...
Open a subproject about distribution mechanisms: how to actually
build our fine high-level protocols on existing low-level ones...
Find all Migration topics.
Find all implementational problems.
Make first proposals.
Divide into subfiles.
Add pointers to Sony, Shapiro, etc
Back to the
Tunes Home page.
Page Maintainer:
Faré
-- rideau@clipper.ens.fr