对于纯粹的、功能性的、热切评估的语言，垃圾收集器可以安全地做出哪些假设？答案

【问题标题】：What assumptions could a garbage collector for a pure, functional, eagerly-evaluated language safely make?对于纯粹的、功能性的、热切评估的语言，垃圾收集器可以安全地做出哪些假设？
【发布时间】：2018-03-29 17:19:24
【问题描述】：

稍微澄清一下问题：

JVM 使用的垃圾收集器由于其支持的语言的性质而涉及很多复杂性。与 JVM 垃圾收集器相比，专为纯粹的、功能性的、热切评估的编程语言而构建的垃圾收集器会得到哪些简化？

【问题讨论】：

这是一个非常广泛的问题，可能会写满整本书。你能进一步缩小范围吗？
您对缩小范围有什么建议吗？
不，不是。你在这里画大笔画。我什至不知道从哪里开始。
我想如果我知道如何缩小问题的范围，我一开始就不需要问它。考虑到它们支持的语言，两个 GC 必须适应的内容几乎可以肯定存在一些非常具体的高级差异，而我要问的是这些具体差异。
值得一问：cs.stackexchange.com/questions/tagged/garbage-collection

标签： functional-programming garbage-collection jvm

【解决方案1】：

我几乎不是函数式语言设计方面的专家，但是在考虑您的问题时，我立即想到了以下主题：

很可能会是 世代 GC，至少我认为没有理由不这样做。它可能会从调整大量临时对象中受益
无 write-barriers - 由于不可变性，无法创建从旧对象到新对象的引用。没有从旧到新的引用意味着在分代 GC 的情况下不需要记住的集合，因此不需要写屏障来管理它们。在我看来，这是一个很好的简化。
更简单的安全点 - 由于函数式语言的性质，函数调用比面向对象编程更密集。甚至循环也可以定义为递归函数调用。这应该使实现 GC 安全点更容易 - 例如，只需在每个函数条目上。例如，阅读this article 作为参考。
no pinning - 如果我们假设的纯函数式语言不支持本地代码协作，则在压缩 GC 的情况下不需要对象固定。这可以大大简化其设计。
no finalization - 对象最终化可能不适合纯函数式语言。我觉得它破坏了参考透明度。如果我们不支持原生资源，那么一开始就不需要它。

【讨论】：