純粋な言語のガベージコレクションはどのように異なりますか？
Haskellのような純粋な言語では、すべてのデータは不変であり、既存のデータ構造を変更することはできません。さらに、不変のデータと関数型プログラミングパターンの多くのアルゴリズムは、本質的に大量のガベージを生成します（たとえば、中間リストを作成するmapのチェーン）。
ガベージコレクターは、他の方法では不可能である純度に直面して、どのような戦略と手法を採用していますか？純粋なコンテキストではない不純な言語のGCでうまく機能するものは何ですか？純粋な言語がGCにもたらす他の新しい問題は何ですか？
Ghcの現在の実装は、言語が純粋に機能的でデータが不変であるためにのみ機能する戦略を使用します。新しいものを参照するために変数を変更することはできず、オブジェクトは古いオブジェクトへの参照しか保持しないため、世代別ガベージコレクターを実行します。 ;上位の世代によって参照されるオブジェクトは、その世代がGCdになるまで削除できないため、オブジェクトをより高い世代に積極的に昇格させます。そして、GCが参照をスイープしている間は参照を変更する予定がないため、並列に実行できます。
こちらが 詳細な論文 です。
Haskellのような純粋な言語では、すべてのデータは不変であり、既存のデータ構造を変更することはできません。
実際、それは一般的に真実ではありません。純粋な言語は非厳密な（遅延）評価を使用するため、潜在的にすべての部分式の評価は延期されます。評価されていない式は通常、「サンク」としてヒープに割り当てられます。必要に応じて式が評価され、サンクは結果の値にmutatedされます。
ガベージコレクターは、他の方法では不可能である純度に直面して、どのような戦略と手法を採用していますか？
私が考えることができる唯一のことは、 ブラックホール です。 HaskellのリサーチペーパーでGC側に何か新しいものを見た覚えはありません。
純粋なコンテキストではない不純な言語のGCでうまく機能するものは何ですか？
GC書き込みバリア。不純な言語は、ヒープにポインタをより多く書き込む傾向があるため、書き込みバリアをより最適化する傾向があります。
Mark-regionなどの他のGCアルゴリズムは、純粋な言語よりも割り当て率が低くなる可能性があるため、不純な言語のコンテキストでははるかに実行可能です。
純粋な言語がGCにもたらす他の新しい問題は何ですか？
純粋な言語は非常にまれであるため、純粋なプログラムがどのようにメモリを使用するかについてのデータははるかに少なく、したがって、純粋な言語用のGCを記述しようとすると、より悪い位置から始めます。