Fuel is a tool for fast object deployment that stores objects and restores them quickly. Its main goals are to work with any type of object but focus on classes and methods, have minimal loading size, and allow flexible reading of stored streams including brief info extraction and partial loading. It addresses challenges like preserving object identity, detecting cycles, handling class shape changes, and working across versions and dialects. Its solution clusters objects during storage and uses iterative rather than recursive loading to reconstruct the graph efficiently.

1. Fuel
a fast and flexible object deployment tool

2. Intro

3. Goal in a nutshell
Store objects and restore them fast.
The store time is
desired but not
the focus.
It will work with any
kind of objects, but its
main goal is with
classes and methods.

4. Other goals
● Have a minimal loading package (to work in
Seed kernels).
● Be useful for Marea project.
● Other projects can use it for storing their objects
(for example, a Fuel export/import extension is
being integrated on Moose Suite).
● Maybe also allow to choose a fast-storing write
strategy (for these cases in which there is no
worry for for reading time but for writing).

5. Other goals (II)
● Allow other ways of reading the stream:
● Brief info extraction: do a light read of the stream, to
extract some information without restoring the
objects.
● Partial loading: sometimes we don't want to restore
entirely the stored graph.

6. Problems

7. Identity: reference vs. creation
● Certain objects in the image must preserve its
identity
● i.e. when loading, certain objects correspond to
ones already present in the system, and so
should't be created 'duplicating' them.
● Some of them should be detected implicitly, like
the Smalltalk globals.
● Another ones should be explicited by the user.
A typical example are the singleton instances,
MyModel uniqueInstance.

8. Cycles
● When traversing the
graph is necessary to
check for cycles.
● This check has a high
cost, but only affects
on storing time.

9. Class shape changing
When loading an object,
it can happen that its
class has changed. So
we could:
● Have some automatic
tolerance.
● Help the user to solve
conflicts easily.

10. Portability
● Between Fuel versions:
● When restoring from a stream, we should look what
version was used to store it, and then act in
consequence.
● Between Pharo versions:
● Suppose that CompiledMethod implementation
changes. We should be able to adapt the original
format, or at least detect a problem and throw an
error.
● Between dialects:
● At the moment is not a goal.

11. Minimal loading
● Fuel would be used for binary loading of
packages in a minimal system, even without a
Compiler.
● The packages for loading should work alone.
Independent of the ones for storing.

12. Known implementations
● Parcels (VW)
● ReferenceStream / SmartRefStream
● Magma
● Monticello2
● SRP (VW)
● BOSS (VW)
● ObjectDumper (GNU Smalltalk)
● SIXX

13. Our solution

14. Principles
On its pickle format, Fuel takes two ideas used in
Parcels:
● Clustering the objects of the graph.
● Iterative loading, to avoid recursive parsing
algorithms.

15. Clustering
● The objects of the graph will be stored in a
sequence of clusters.
● Each cluster groups instances that share
loading information.
● That shared information is stored once,
reducing the overhead when loading.

16. Iterative loading
● The loading process is done by reading linearly
the stream, without a recursive algorithm to
reconstruct the graph.
● The graph is stored in two parts:
● Vertexes: Information for the instantiation of the
objects.
● Edges: Information for restoring the references
between objects.