User's Guide
The current Swapper implementation presents some
limitations, which are listed below.
- Any object containing an instance of CompiledMethod will not be
unloaded. (This can be overridden with certain restrictions described
in CompiledMethods).
- Classes are unloaded by using "lightweight" dumping replacements in a
transparent manner. (An override is provided to allow dumping of
specified classes as normal objects for specialized applications that require
it). Lightweight here means that a compact representation is dumped for
classes.
- If an error occurs during loading then the entire operation is
aborted. There is no partial completion of the loading
operation. The position at the swapping stream is not specified when
the operation is aborted.
- Objects dumped by this release of the Swapper can not be loaded by
previous releases.
- Special care should be taken when packaging an application for run
time. Because of the way in which instance variable based replacement
works, and the way in which dumping replacements are implemented (instance
variables such as description of ClassDescription are
used), you should be aware that they cannot be removed in a runtime
image. They can be nil, but they must be present.
Also, the names of instance variables of a given class (instance variable
instVarNames in ClassDescription) should be present and
not nil at runtime so that checking can be done and proper mutation
performed.
- Classes such as SmallInteger, True,
False, Character and UndefinedObject should
not define any loading or dumping replacement. They are special classes
and optimizations in the dumping and loading process do not guarantee that a
replacement object will be asked for objects of these classes.
- Since the Swapper is now a framework, you can redefine replacement
behavior. Due to internal optimizations, by default, not all loaded
objects are asked for their loading replacement. So, when you define
new loading replacement methods, make sure you also perform one of the
following:
- Turn off loading optimization for the instance of ObjectLoader
you use. You can use ObjectLoader instance method
optimizeLoadingReplacement:. This forces the loader to
send the message (that computes loading replacement) to all objects
loaded. This makes the loading itself a bit slower, though how much
slower will depend on the number of objects you are loading, since it is an
extra message send per loaded object.
- Define class method definesLoadingReplacement in the class that
needs a loading replacement, and make it return true. Do
this before dumping your objects. When dumping, the
ObjectDumper recognizes instances of this class as objects that
need to be processed on load, and makes sure that the ObjectLoader
used, even when optimization is turned on, computes a loading replacement for
instances of this class. Performance will still be optimal.
Collisions of method names in the same class can be solved by the use of
strategies. See The Swapper framework.
- When you redefine class-based and instance-variable-based replacement, you
also need to define the class methods definesClassBasedReplacement
and definesInstVarReplacement respectively to return
true, so that the ObjectDumper can know whether
instances of this class need to be sent messages to compute a
replacement. Collisions of method names in the same class can be solved
by the use of strategies. See The Swapper framework.
[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]