From delivery level 2 upward, the image is "shaken" by default during delivery with the treeshaker. You can also invoke the treeshaker directly with the
deliver
keyword
:shake-shake-shake.
As discussed above, the garbage collector does not delete any interned symbols, class definitions, or methods discriminating on classes from the image, even when they are unused. This is because it is designed to keep any object for which a reference exists.
There are always references to interned symbols, class definitions, and methods discriminating on classes. Interned symbols, naturally, are referred to by their package. Class definitions are always pointed to by their superclasses (the root class,
t
, has no superclass but is protected from garbage collection), and a method discriminating on a class is always pointed to by the class.
Thus we have a special class of objects that cannot be removed under the normal garbage collection scheme. Using the treeshaker, however, we can do so. The treeshaker does the following to overcome the default links between these objects:
Step Break the links. renders the objects the same as all others in the image. They are now only protected from garbage collection if there are links to them elsewhere in the image -- that is, if they are actually used in the application.
The term "treeshaker" is derived from the notion that the routine picks up, by its root, a tree comprising the objects in the image and the links between them, and then shakes it until everything that is not somehow connected to the root falls off, and only the important objects remain. (An image would usually be better characterized as a directed graph than a tree, but the metaphor has persisted in the Lisp community.)
LispWorks Delivery User Guide - 13 Dec 2011