SBCL has the ability to save its state as a file for later execution. This functionality is important for its bootstrapping process, and is also provided as an extension to the user.
&keyarguments are defined:
- The function to run when the created core file is resumed. The default function handles command line toplevel option processing and runs the top level read-eval-print loop. This function returning is equivalent to (SB-EXT:QUIT
:unix-status0) being called.
- If true, arrange to combine the
sbclruntime and the core image to create a standalone executable. If false (the default), the core image will not be executable on its own. Executable images always behave as if they were passed the –noinform runtime option.
- If true, values of runtime options –dynamic-space-size and –control-stack-size that were used to start
sbclare stored in the standalone executable, and restored when the executable is run. This also inhibits normal runtime option processing, causing all command line arguments to be passed to the toplevel. Meaningless if
- If true (the default on cheneygc), do a purifying
gcwhich moves all dynamically allocated objects into static space. This takes somewhat longer than the normal
gcwhich is otherwise done, but it's only done once, and subsequent GC's will be done less often and will take less time in the resulting core file. See the
purifyfunction. This parameter has no effect on platforms using the generational garbage collector.
- This should be a list of the main entry points in any newly loaded systems. This need not be supplied, but locality and/or
gcperformance may be better if they are. Meaningless if
nil. See the
- This is also passed to the
t. (rarely used)
The save/load process changes the values of some global variables:
- Everything related to open streams is necessarily changed, since the
oswon't let us preserve a stream across save and load.
- This is reinitialized to reflect the working directory where the saved core is loaded.
sb-alien:load-foreign-object:see its documentation for details.
On threaded platforms only a single thread may remain running after
sb-ext:*save-hooks*have run. Applications using multiple threads can be
save-lisp-and-diefriendly by registering a save-hook that quits any additional threads, and an init-hook that restarts them.
This implementation is not as polished and painless as you might like:
This isn't because we like it this way, but just because there don't seem to be good quick fixes for either limitation and no one has been sufficiently motivated to do lengthy fixes.
- It corrupts the current Lisp image enough that the current process needs to be killed afterwards. This can be worked around by forking another process that saves the core.
- There is absolutely no binary compatibility of core images between different runtime support programs. Even runtimes built from the same sources at different times are treated as incompatible for this purpose.
To facilitate distribution of SBCL applications using external resources, the filesystem location of the SBCL core file being used is available from Lisp.