哪个有更好的垃圾收集，MRI 2.2 或 Rubinius 2.5.3答案

【问题标题】：Which has better garbage collection, MRI 2.2 or Rubinius 2.5.3哪个有更好的垃圾收集，MRI 2.2 或 Rubinius 2.5.3
【发布时间】：2015-05-02 01:53:32
【问题描述】：

MRI 2.2 自 2.1 以来对 GC 进行了一些重大改进，即增量 GC，现在它可以垃圾收集符号。

一个人通过升级 MRI 修复了他的内存泄漏，请参阅 this blog post

我们不久前切换到 Rubinius，其中一个原因是我们认为它具有出色的垃圾收集能力。

Rubinius 似乎不会垃圾收集符号，请参阅此issue。情况仍然如此吗？ GC-ing 符号是一个很大的改进吗？

我在 rubinius 中阅读了有关 concurrent GC 的信息，它似乎解决了与 MRI 的增量 GC 相同的问题，即消除了较长的 GC 暂停时间。我也在 rubinius 中看到了this description of generational GC。但是，我不知道如何将 MRI GC 与 RBX GC 比较。

那么有谁知道哪个更好？

【问题讨论】：

您必须考虑到 MRI 是单线程的，而 rubinius 是多线程的。这会影响每单位 walltime 可以分配多少对象，从而影响收集器必须做的工作量。
那么 Rubinius 分配的每单位 walltime 的对象是少是多？ Rubinius 收藏家还需要做更多的工作？

标签： ruby garbage-collection rubinius

【解决方案1】：

Rubinius 似乎不会垃圾收集符号，请参阅此问题。情况仍然如此吗？ GC-ing 符号是一个很大的改进吗？

Rubinius 目前不对符号进行垃圾收集。我们最终会添加它，但现在有更紧迫的问题需要处理（例如，对 LLVM 3.6/MCJIT 的支持）。

被 GC 处理的 Symbols 是否会有所改进取决于您的应用程序。如果所述应用程序正在创建大量很少使用的符号，那么可以肯定，它可以为您节省一些内存。解决这个问题的最佳方法是在切换到收集符号的 GC 之前/之后测量内存使用情况。

那么有谁知道哪个更好？

Rubinius 的 GC 旨在减少和缩短暂停（它不是 100% 并发，这意味着它确实仍然会偶尔暂停所有内容）并且旨在精确（意味着它确切地知道要做什么）收集而不是丢失对象）。这是否会再次导致出色的垃圾回收取决于您正在运行的应用程序的类型。

【讨论】：