ガベージコレクションされたプログラミング言語で指定された最悪のデータ構造の実行時間を分析するとき、GCのコストを無視できますか？

私は自分の質問への答えが「はい」であると仮定してきたことに気付いたが、正当な理由はない。おそらく、ワーストケースのスローダウンのみを導入するガベージコレクターがあると思います。引用できる決定的なリファレンスはありますか？私の場合、純粋に機能的なデータ構造に取り組んでおり、これらの詳細が重要な場合は標準MLを使用します。$O(1)$

そしておそらく、この質問は、たとえばJavaで指定されたデータ構造に適用されると、さらに関連性が高くなるでしょうか？Javaを使用するアルゴリズム/データ構造の教科書に関連する議論があるかもしれません。（SedgewickにはJavaバージョンがあることは知っていますが、Cバージョンにしかアクセスできません。）

はい、gcは一定時間で償却されます。サイズピークワーキングセットで時間で実行するアルゴリズムがあるとします。ここで、プログラムの実行中に最大でワードを割り当てることができ、コピーガベージコレクターを実行する時間コストはあることに注意してください（つまり、gcのコストは合計に比例しますライブデータの量）。そのため、gcを最大回実行すると、総実行時コストはによって制限されます。つまり、gcの償却コストは一定です。したがって、各セミスペースがサイズチェイニースタイルのコレクターがある場合は、完全なコレクションを2回以上呼び出すことはできません。$n$$k$$O(n)$$O(k)$$O(n/k)$$O(n)$$2k$$n/k$ステップ。これは、ワードの割り当てに時間かかり、ワーキングセットがサイズを超えることはないため、必要な境界が得られます。これにより、GCの問題を無視できます。$k$$O(k)$$k$

ただし、gcの有無が無視できない1つのケースは、ロックフリーのデータ構造を書き込むときです。最新のロックフリーデータ構造の多くは、意図的にメモリをリークし、正確性をgcに依存しています。これは、高レベルでは、一部のデータをコピーし、変更を加え、CAS命令でアトミックに更新し、CASが成功するまでループでこれを実行することであるためです。これらのアルゴリズムに決定論的な割り当て解除を追加すると、アルゴリズムがはるかに複雑になるため、人々は気にしません（特にJavaのような環境をターゲットにしていることが多いため）。

編集：償却されていない境界が必要な場合、チェイニーコレクターはそれを行いません-呼び出されるたびにライブセット全体をスキャンします。グーグルのキーワードは「リアルタイムガベージコレクション」であり、Djikstra et al。スティールが最初のリアルタイムマークアンドスイープコレクターを提供し、ベイカーが最初のリアルタイムコンパクト化gcを提供しました。

@article {dijkstra1978fly、
  title = {{オンザフライガベージコレクション：協力の演習}}、
  author = {Dijkstra、EWおよびLamport、L。およびMartin、AJおよびScholten、CSおよびSteffens、EFM}、
  journal = {ACMのコミュニケーション}、
  ボリューム= {21}、
  番号= {11}、
  pages = {966--975}、
  issn = {0001-0782}、
  年= {1978}、
  パブリッシャー= {ACM}
}

@article {steele1975multiprocessing、
  title = {{ガーベジコレクションを圧縮するマルチプロセッシング}}、
  author = {Steele Jr、GL}、
  journal = {ACMのコミュニケーション}、
  ボリューム= {18}、
  番号= {9}、
  pages = {495--508}、
  issn = {0001-0782}、
  年= {1975}、
  パブリッシャー= {ACM}
}

@article {baker1978list、
  title = {{シリアルコンピューターでのリアルタイムのリスト処理}}、
  author = {ベイカーJr、HG}、
  journal = {ACMのコミュニケーション}、
  ボリューム= {21}、
  番号= {4}、
  pages = {280--294}、
  issn = {0001-0782}、
  年= {1978}、
  パブリッシャー= {ACM}
}

ガベージコレクションは無視できると思います。興味深いことに、おそらく、ガベージコレクションについて読んだすべての作業では、計算の複雑さについて言及していません。これは、アルゴリズムがヒープのサイズがであるためですが、通常、呼び出されるたびにヒープ全体をスキャンするわけではありません。$O(n)$

ガベージコレクションの主な問題は、計算の複雑さではなく、予測不可能性です。これは、リアルタイムシステムを検討する際に最も重要です。リアルタイムガベージコレクションに関する多くの作業がこの問題に対処しようとしています。他の人は単にあきらめました。たとえば、Javaのリアルタイム仕様は、サイズに関係なく、コストでプログラムによって割り当ておよび割り当て解除されるプログラマー指定の領域に依存しています。$O(1)$

決定的なガベージコレクションのリファレンスは次のとおりです。

• リチャードジョーンズとラファエルリンによるガベージコレクション

Ben Zornは、さまざまなガベージコレクションアルゴリズムの実際のコストを測定する作業を行いましたが、最近の論文では、より包括的な比較が行われています。

• 神話と現実：ガベージコレクションのパフォーマンスへの影響、SMブラックバーン、P。チェン、およびKSマッキンリー、ACM SIGMETRICS Conference on Measurement＆Modeling Computer Systems、pp.25--36、ニューヨーク、NY、2004年6月

詳しくは：

• ガベージコレクションの統一理論、Bacon、Cheng、およびRajan、ACM Conference on Object-Oriented Programming、Systems、Languages、およびApplications、バンクーバー、BC、カナダ、pp。50-68、2004