1.0.21.15: LOAD-SHARED-OBJECT :DONT-SAVE and related
[sbcl.git] / src / code / save.lisp
index cff44fc..76b6e5b 100644 (file)
 
 (define-alien-routine "save" (boolean)
   (file c-string)
-  (initial-fun (unsigned #.sb!vm:n-word-bits)))
+  (initial-fun (unsigned #.sb!vm:n-word-bits))
+  (prepend-runtime int))
 
 #!+gencgc
 (define-alien-routine "gc_and_save" void
-  (file c-string))
+  (file c-string)
+  (prepend-runtime int))
 
 #!+gencgc
 (defvar sb!vm::*restart-lisp-function*)
 
 (defun save-lisp-and-die (core-file-name &key
                                          (toplevel #'toplevel-init)
-                                         (purify #!+gencgc nil
-                                                 #!-gencgc t)
+                                         (purify t)
                                          (root-structures ())
-                                         (environment-name "auxiliary"))
+                                         (environment-name "auxiliary")
+                                         (executable nil))
   #!+sb-doc
   "Save a \"core image\", i.e. enough information to restart a Lisp
 process later in the same state, in the file of the specified name.
@@ -47,15 +49,19 @@ The following &KEY arguments are defined:
      and runs the top level read-eval-print loop. This function should
      not return.
 
+  :EXECUTABLE
+     If true, arrange to combine the SBCL runtime and the core image
+     to create a standalone executable.  If false (the default), the
+     core image will not be executable on its own.
+
   :PURIFY
      If true (the default on cheneygc), do a purifying GC which moves all
      dynamically allocated objects into static space. This takes
      somewhat longer than the normal GC which 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 PURIFY
-     function. For platforms that use the generational garbage collector
-     (x86 and x86-64) purification generally results in a loss of
-     performance.
+     function. This parameter has no effect on platforms using the
+     generational garbage collector.
 
   :ROOT-STRUCTURES
      This should be a list of the main entry points in any newly loaded
@@ -77,19 +83,18 @@ The save/load process changes the values of some global variables:
     This is reinitialized to reflect the working directory where the
     saved core is loaded.
 
-Foreign objects loaded with SB-ALIEN:LOAD-SHARED-OBJECT are
-automatically reloaded on startup, but references to foreign symbols
-do not survive intact on all platforms: in this case a WARNING is
-signalled when saving the core. If no warning is signalled, then the
-foreign symbol references will remain intact. Platforms where this is
-currently the case are x86/FreeBSD, x86/Linux, x86/NetBSD,
-sparc/Linux, sparc/SunOS, and ppc/Darwin.
+SAVE-LISP-AND-DIE interacts with 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-DIE friendly 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:
   * 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.
-  * It will not work if multiple threads are in use.
   * 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
@@ -97,6 +102,9 @@ 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."
+  #!+gencgc
+  (declare (ignore purify root-structures environment-name))
+  (tune-hashtable-sizes-of-all-packages)
   (deinit)
   ;; FIXME: Would it be possible to unmix the PURIFY logic from this
   ;; function, and just do a GC :FULL T here? (Then if the user wanted
@@ -113,15 +121,18 @@ sufficiently motivated to do lengthy fixes."
                ;; A normal GC will leave huge amounts of storage unreclaimed
                ;; (over 50% on x86). This needs to be done by a single function
                ;; since the GC will invalidate the stack.
-               #!+gencgc (gc-and-save (unix-namestring core-file-name nil)))
+               #!+gencgc (gc-and-save (unix-namestring core-file-name nil)
+                                      (if executable 1 0)))
              (without-gcing
               (save (unix-namestring core-file-name nil)
-                    (get-lisp-obj-address #'restart-lisp)))))
+                    (get-lisp-obj-address #'restart-lisp)
+                    (if executable 1 0)))))
     ;; Save the restart function into a static symbol, to allow GC-AND-SAVE
     ;; access to it even after the GC has moved it.
     #!+gencgc
     (setf sb!vm::*restart-lisp-function* #'restart-lisp)
-    (cond (purify
+    (cond #!-gencgc
+          (purify
            (purify :root-structures root-structures
                    :environment-name environment-name)
            (save-core nil))
@@ -132,11 +143,12 @@ sufficiently motivated to do lengthy fixes."
            (save-core t)))))
 
 (defun deinit ()
-  (dolist (hook *save-hooks*)
-    (with-simple-restart (continue "Skip this save hook.")
-      (funcall hook)))
-  #!-win32 (when (fboundp 'cancel-finalization)
-    (cancel-finalization sb!sys:*tty*))
+  (call-hooks "save" *save-hooks*)
+  (when (rest (sb!thread:list-all-threads))
+    (error "Cannot save core with multiple threads running."))
+  (float-deinit)
   (profile-deinit)
   (debug-deinit)
-  (foreign-deinit))
+  (foreign-deinit)
+  (stream-deinit)
+  (deinit-finalizers))