MRI 2.2 は 2.1 以降、GC でいくつかの大きな改善がありました。つまり、インクリメンタル GC であり、現在ではシンボルをガベージ コレクションします。
あるフェローは、MRI をアップグレードするだけでメモリ リークを修正しました。このブログ投稿を参照してください。
しばらく前に Rubinius に切り替えましたが、その理由の 1 つは、ガベージ コレクションが優れていると考えたからです。
Rubinius はシンボルをガベージ コレクションしないようです。この問題を参照してください。これは今でも当てはまりますか? シンボルを GC することで大きな改善が見られますか?
rubinius のコンカレント GCについて読んだことがあります。これは、MRI のインクリメンタル GC と同じ問題に対処しているようです。つまり、長い GC 一時停止時間を取り除くことです。rubiniusの世代別 GC の説明も見ました。ただし、RBX GC に対して MRI GC のサイズを大きくする方法がわかりません。
それで、誰が優れているか知っていますか？
Rubinius はシンボルをガベージ コレクションしないようです。この問題を参照してください。これは今でも当てはまりますか? シンボルを GC することで大きな改善が見られますか?
Rubinius は現在、シンボルをガベージ コレクションしません。これは最終的に追加する予定ですが、今のところは、対処すべき差し迫った問題が他にもあります (例: LLVM 3.6/MCJIT のサポート)。
GC されたシンボルが改善されるかどうかは、アプリケーションによって異なります。上記のアプリケーションが、めったに使用されないシンボルを大量に作成している場合は、メモリを節約できます。これを把握する最善の方法は、シンボルを収集する GC に切り替える前後のメモリ使用量を測定することです。
それで、誰が優れているか知っていますか？
Rubinius の GC は、一時停止をより少なく、より短くすることを目指しており (100% の同時実行ではなく、時々すべてを一時停止することを意味します)、正確であることを目指しています (つまり、欠落しているオブジェクトではなく、何を収集するかを正確に認識しているということです)。これによりガベージ コレクションが再び優れたものになるかどうかは、実行しているアプリケーションの種類によって異なります。