Moving objects to a new container is a problem everyone in R&D has faced at least once in his life. It requires a very advanced algorithm to pack the many different objects (which are generally heterogeneous, with different uses, types, weights and sizes), before the packs can then be transferred to the new container, generally through a dedicated bus. We can identify some usual cases:

• In the worst case, the new container can be smaller than the old one, and a garbage collector is generally used to help find a solution that satisfies the problem (a SAT solver can be used to determine which objects should be destroyed).
• In the best case, the new container is bigger than the old one, but also very close to the old one and many resources are available, enabling the use of multi-threading to accelerate the migration.
• The average case is that the new container is slightly bigger, and not too far, with some shared resources available.

Parameters that should generally be considered include:

• Size of old and new containers
• Distance between the containers
• Amount of objects
• Amount of available resources
• Size and bandwidth of the bus for transporting the object packs
• Maximum duration for the migration
• The timing of the migration (the process might create some overheating, and can be impacted by component freezes)

Unfortunately, there is no single solution for all migration cases and a self-adaptive (in order to react to the surrounding entropy) algorithm must be created in a JIT-way depending on the parameters. I will investigate a toolkit-agnostic method to optimize the creation of such algorithms.

Or in other words: I'm taking a week of FTO to pack stuff to move to a new house ;-) Everybody's welcome to join, obviously!