SBCL 的 REPL 中的内存泄漏
我对 REPL 中 SBCL 垃圾收集器的以下行为感到有些困惑。定义两个函数：
(defun test-gc ()
(let ((x (make-array 50000000)))
(elt x 0)))
(defun add-one (x) (+ 1 x))
然后运行
(add-one (test-gc))
我希望没有任何东西再引用原始数组。然而，正如（房间）报告的那样，内存并未被释放。我会理解，如果我直接运行 (test-gc)，那么某些引用可能会卡在 SLIME 或中的某个位置，
(list * ** ***)
但是这里是这种情况吗？谢谢，安德烈。
更新 前段时间我提交了一个错误。最近这一消息得到了证实。看： https://bugs.launchpad.net/sbcl/+bug/936304
I'm somewhat baffled by the following behaviour of SBCL garbage collector in REPL. Define two functions:
(defun test-gc ()
(let ((x (make-array 50000000)))
(elt x 0)))
(defun add-one (x) (+ 1 x))
Then run
(add-one (test-gc))
I would expect that nothing references the original array anymore. Yet, as (room) reports, the memory is not freed. I would understand, if I ran (test-gc) directly, then some reference could have been stuck somewhere in SLIME or in
(list * ** ***)
But was is the case here? Thanks, Andrei.
Update Some time ago I filed a bug. It was recently confirmed. See:
https://bugs.launchpad.net/sbcl/+bug/936304
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
仅仅因为没有任何东西再引用这些对象并不意味着内存将被回收。垃圾收集器将在将来的某个时间运行，并且通常您获得的唯一保证是它将在出现内存不足错误之前运行。
这里可能发生的另一件事是您正在查看 Lisp 进程的内存使用情况。当内存被 CG'ed 时，它通常不会返回到操作系统。相反，内存只是在堆上标记为空闲，并且可以在将来的内存分配中使用。
Just because nothing references the objects anymore doesn't mean that the memory will be reclaimed. The garbage collector will be run some time in the future, and often the only guarantee that you get is that it will be run before you get an out of memory error.
Another thing that may happen here is that you are looking at the Lisp process memory usage. When memory is CG'ed it is generally not returned to the operating system. Instead, the memory is simply marked as free on the heap, and can be used in future memory allocations.
仅限 SBCL...
(gc :full t)这将强制启动跨所有代的垃圾收集。我注意到 SBCL 几天前占用了大量内存，并使用它来将内存降低到“真实”使用量。
然后我编写了一个 Ensure-gc 宏来包装我的垃圾计算&实验的东西。如果我记得的话，我回家后会把它粘贴进去……这没什么奇怪的。
SBCL only...
(gc :full t)This will forcibly kick off a garbage collection across all generations. I noticed SBCL was holding onto a ton of memory a few days ago and used this to drop the memory down to the "true" usage.
I then wrote an ensure-gc macro to wrap my garbagey computation & experimentation stuff in. I'll paste it in when I get home if I remember... it's nothing fancy.