具备并发垃圾回收器的函数式语言？

Question

微软的新编程语言F#提供了强大的功能编程（一级词法闭包和尾调用）与高效的并发垃圾回收器的结合，使得利用多核变得容易。

我所知道的OCaml、Haskell、Erlang以及所有免费的Lisp和Scheme实现都没有并发GC。Scala和Clojure有并发GC但没有尾调用。

因此，似乎没有开源编程语言结合这些特性。这是正确的吗？

- Jon Harrop

---

注意，根据http://blogs.msdn.com/clyon/archive/2004/09/08/226981.aspx，微软的并发GC是单线程的（非并行）。他们提供了一个并行GC（“服务器GC”），它不是并发的，但他们声称其吞吐量比并发GC更高。 - cjs

请注意，您引用的博客文章是2004年的，.NET GC已在.NET 3.5 SP1中被新的“后台GC”所取代。 - J D

Answer 1

Erlang采用共享无模型，每个进程都有自己的垃圾回收器。你认为它是否具有并发性取决于你。但随着进程数的增加，它的扩展性非常好。

- svenningsson

---

Erlang如何处理从一个进程传递到另一个进程的数据？它会在每次传输时复制吗？ - Yoric

一般来说，是的，因为Erlang支持无缝分布。实现可能在进程之间共享内存，但我认为现有的任何实现都没有这样做。 - svenningsson

Answer 2

最新版本的GHC支持并行GC。请查看发行说明。

- Claymore

---

我本来也想注意到这一点，但是并行垃圾回收和并发垃圾回收不是同一回事。 - mipadi

确实。这就是为什么 Haskell 的 GC 无法扩展的原因。 - J D

这个要看你想要扩展什么。正如我上面指出的，微软实际上提供了一个非并发的垃圾回收器，因为它在吞吐量方面比并发的垃圾回收器更好扩展。 - cjs

@Curt：扩展性和吞吐量不是同一回事。.NET的非并发并行“服务器”GC选项为了提高吞吐量而牺牲了延迟。如果你运行一个程序，每个核心都有一个线程，只有一个线程分配重量，那么你会发现服务器GC比默认的并发GC扩展性要差得多，因为那个线程会降低所有其他线程的性能，而这些线程使用的是非并发GC。Haskell和默认的JVM GC也存在同样的问题。因此我说Haskell的GC不具备扩展性。 - J D

我不明白，如果你正在生成大量垃圾并且不关心延迟（比如运行几个小时的分析程序，只需查看最终结果），一个速度增加的并行GC（即，你花费更少的墙钟时间进行GC）为什么不是“可扩展”的。当你给GC更多核心时，程序难道不会以更快的速度（在墙钟时间内）运行吗？ - cjs

@Curt：你忽略了“停止一切”阶段对可扩展性的主导贡献。 - J D

Answer 3

Scala有一些尾递归优化。但是要完整地使用它，请使用SISC方案。

- Craig Stuntz

Answer 4

这并不是你问题的答案，但据我所知，F#使用标准的.NET垃圾回收器，它不是并发的；在GC期间所有线程都会停止。

编辑: 我错了，在多处理器模式下有一个并发GC。

- Stephan Leclercq

---

.NET支持并发GC（至少对于2级收集），请参见http://blogs.msdn.com/clyon/archive/2004/09/08/226981.aspx和http://www.julmar.com/blog/mark/PermaLink，guid，3670d081-0276 -48e6-b97d-1b644093b52e.aspx。 - Rob Walker

Answer 5

Java据说正在添加尾调用。当这发生时，Clojure也会得到它们。与此同时，您可以使用loop/recur机制手动获取它们。

- Lou Franco

---

循环/递归将为您提供尾递归（对自身的尾调用），但不包括一般的尾调用。 - bendin