0.9.2.37:

[sbcl.git] / src / code / gc.lisp

diff --git a/src/code/gc.lisp b/src/code/gc.lisp
index af6a759..1acfa9c 100644 (file)
--- a/src/code/gc.lisp
+++ b/src/code/gc.lisp
@@ -208,8 +208,11 @@ environment these hooks may run in any thread.")
   (sb!thread:make-mutex :name "GC lock") "ID of thread running SUB-GC")
 
 (defun sub-gc (&key (gen 0))
-  (unless (eql (sb!thread:current-thread-id)
-              (sb!thread::mutex-value *already-in-gc*))
+  (unless (eq sb!thread:*current-thread*
+              (sb!thread::mutex-value *already-in-gc*))
+    ;; With gencgc, unless *NEED-TO-COLLECT-GARBAGE* every allocation
+    ;; in this function triggers another gc, potentially exceeding
+    ;; maximum interrupt nesting.
     (setf *need-to-collect-garbage* t)
     (when (zerop *gc-inhibit*)
       (sb!thread:with-mutex (*already-in-gc*)
@@ -232,9 +235,10 @@ environment these hooks may run in any thread.")
            ;; current belief is that it is part of the normal order
            ;; of things and not a bug.
            (when (plusp freed)
-             (incf *n-bytes-freed-or-purified* freed)))
-         (sb!thread::reap-dead-threads)))
-      ;; Outside the mutex, these may cause another GC.
+             (incf *n-bytes-freed-or-purified* freed)))))
+      ;; Outside the mutex, these may cause another GC. FIXME: it can
+      ;; potentially exceed maximum interrupt nesting by triggering
+      ;; GCs.
       (run-pending-finalizers)
       (dolist (hook *after-gc-hooks*)
        (handler-case
@@ -293,4 +297,3 @@ environment these hooks may run in any thread.")
   "Disable the garbage collector."
   (setq *gc-inhibit* 1)
   nil)
-