純粋な言語のガベージコレクションはどの程度違いますか？

Haskellのような純粋な言語では、すべてのデータは不変であり、既存のデータ構造は一切変更できません。さらに、不変データおよび関数型プログラミングパターンに関する多くのアルゴリズムは、本質的に大量のガベージをmap生成します（たとえば、中間リストの作成のチェーン）。

ガベージコレクターは、他の方法ではできない純度に直面して、どのような戦略と手法を採用していますか？純粋なコンテキストではない不純な言語のGCでうまく機能するものは何ですか？純粋な言語はGCに対して他にどのような新しい問題を引き起こしますか？

現在のghcの実装では、言語が純粋に機能的でデータが不変であるためにのみ機能する戦略を使用します。変数を変更して新しいものを参照することはできないため、オブジェクトは古いオブジェクトへの参照のみを保持するため、世代別ガベージコレクターを実行します; 上位世代が参照するオブジェクトは、その世代がGCdされるまで削除できないため、オブジェクトを上位世代に積極的に昇格させます。また、GCが参照をスイープしている間は何も参照を変更しないため、並行して実行できます。

詳細はこちらの論文をご覧ください。

Haskellのような純粋な言語では、すべてのデータは不変であり、既存のデータ構造は一切変更できません

実際、それは一般的に真実ではありません。純粋な言語は非厳密（遅延）評価を使用するため、潜在的にすべての部分式の評価は延期されます。通常、未評価の式は「サンク」として割り当てられたヒープです。必要なときに式が評価され、サンクがされて変異した値に。

ガベージコレクターは、他の方法ではできない純度に直面して、どのような戦略と手法を採用していますか？

私が考えることができる唯一のものはブラックホールです。Haskellの研究論文でGC側で何か新しいものを見たことを覚えていない。

純粋なコンテキストではない不純な言語のGCでうまく機能するものは何ですか？

GC書き込みバリア。不純な言語は、ポインタをより多くヒープに書き込む傾向があるため、書き込み障壁がより厳しく最適化される傾向があります。

mark-regionなどの他のGCアルゴリズムは、純粋な言語よりも割り当て率がはるかに低い可能性があるため、不純な言語のコンテキストで実行可能です。

純粋な言語はGCに対して他にどのような新しい問題を引き起こしますか？

純粋な言語は非常にまれであるため、純粋なプログラムがメモリを使用する方法に関するデータははるかに少ないため、純粋な言語のGCを作成しようとすると、より悪い位置から開始します。