Tunes Migration Goals
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 object gets abstracted from its current context and applied to another context. There is a conceptual and implementational comparison between Migration and more traditional concepts. See also the Glossary entry for migration.
Migration involves 3 phases:
- The object has to be separated from its current context. Knowledge of the target context is required even at this stage, even if incomplete knowledge. Also, the limitations of the means of transport affects what is required of this stage: a single batch distribution with no opportunity for interaction before the other context must have this distribution running certainly imposes more constraints on what must happen during reification.
- Whatever is separated has to be encoded for transport according to a published medium which both the supplier and consumer support. The publisher of the medium does not have to be an independent or global party. In fact, specializing a globally-published medium for localized conditions is encouraged as long as a bootstrap to implement this localized medium.
- The object is installed into the target context. What is possible here is again dependent on the nature of the communication medium, due to varying natures of installation. For example, dependencies on other versioned objects or meta-objects may be necessary; if those versions are not present on the target machine, they need to be communicated and expressed from some party within the same or another medium, one that is available directly to the context.
Concurrent with these phases is an aspect of translation, handling the semantic and environment differences in various ways. In this respect, this subproject delegates to the HLL Meta-Translator subproject. The translation applies both upon encoding and decoding from the communications phase, and in as often of a case as possible, would be trivial.
- Dynamic Load-balancing
- ...over a pool of resource providers. The system shall automatically dispatch objects across a distributed system. The goal is to improve performance, by reducing overall resources wasted (including being idle, administrating, migrating, and running unoptimized code), while respecting the human user's constraints (response time, total computation time).
- Providing Orthogonal Persistence
- Upgrading Modules
- Fixing bugs, extending, removing features, re-factoring features, and versioning/identification at various levels, including the handling of branching and merging.
- Managing Mobile Users
- Moving users who are logging in on moving places in a computer network.
- Managing Terminals
- Detaching and reattaching objects to different I/O devices, terminals, or whatever. Some of this involves session-management and development for the terminal itself.
All the migration scheduling will be under full user control, be it direct, indirect, remote, purely potential, or freezed to some compile-time behavior.
Migration is a very important feature in the TUNES system, that no other known system provides at all (but in its most primitive, non parametrizable form: swapping raw chunks of memory between memory and harddisk).