タグ付けされた質問 「garbage-collection」

Haskellのような純粋な言語では、すべてのデータは不変であり、既存のデータ構造は一切変更できません。さらに、不変データおよび関数型プログラミングパターンに関する多くのアルゴリズムは、本質的に大量のガベージをmap生成します（たとえば、中間リストの作成のチェーン）。 ガベージコレクターは、他の方法ではできない純度に直面して、どのような戦略と手法を採用していますか？純粋なコンテキストではない不純な言語のGCでうまく機能するものは何ですか？純粋な言語はGCに対して他にどのような新しい問題を引き起こしますか？

26 functional-programming  language-agnostic  garbage-collection 

LMAXのチームがJavaでLMAX Disruptorを設計したのに、GCの使用を最小限に抑えることがすべての設計ポイントであるのはなぜですか？GCを実行したくない場合、ガベージコレクションされた言語を使用するのはなぜですか？ 彼らの最適化、ハードウェアの知識のレベル、そして彼らが置いた思考はただ素晴らしいですが、なぜJavaなのでしょうか？ 私はJavaなどに反対ではありませんが、なぜGC言語なのですか？DのようなものやGCを使用しない他の言語を使用して、効率的なコードを使用できるのはなぜですか？チームはJavaに最も精通しているのでしょうか、それともJavaには私には見られない独自の利点がありますか？ 手動のメモリ管理でDを使用して開発するとしますが、違いは何でしょうか？低レベル（既にある）を考える必要がありますが、システムがネイティブであるため、システムから最高のパフォーマンスを引き出すことができます。

24 java  architecture  performance  garbage-collection  d 

または、言い換えると、自動化されたガベージコレクションはどのような特定の問題を解決しましたか？低レベルのプログラミングを行ったことがないので、リソースの解放がどれほど複雑になるかわかりません。 GCが対処する種類のバグは、（少なくとも外部の観察者にとっては）自分の言語、ライブラリ、概念、イディオムなどをよく知っているプログラマーがしないようなことのように見えます。しかし、私は間違っている可能性があります：手動メモリ処理は本質的に複雑ですか？

24 low-level  garbage-collection 

私は、ガベージコレクションが（理論的には）手動のメモリ管理よりも高速である可能性があることを、多くの場所で読んでいます（実際、自分で書きました）。 ただし、表示することは、伝えることよりもはるかに困難です。この効果が実際に作用することを示すコードを 実際に見たことはありません。 このパフォーマンスの利点を実証するコードを誰かが持っていますか（またはどこにあるかを知っていますか）？

23 memory  garbage-collection 

これは単純な質問のように思えますが、このテーマについて多くのことを読んだ後でも、決定的な答えは見つかりませんでした（おそらくそれはとても単純だからです）。 私の質問はこれです：ガベージコレクターがヒープ内のオブジェクトを圧縮すると、スタック内のオブジェクトへの参照はどのように更新されますか？私は2つの可能な解決策を考えることができます： スタック（およびヒープ内の参照）を調べて、オブジェクトの新しい場所を指すように参照を更新します。引っ越しに例えると、これはあなたの住所を持っている人に手紙を送り、新しい住所で住所録を更新するように頼むようなものです。 何らかのルックアップテーブルを提供します。これは、ローカルの郵便局に転送先を残すようなものです。 ガベージコレクターは主にこれら2つの方法のいずれかを使用しますか？他の方法？どちらも？

18 garbage-collection 

一部の（少なくともMonoおよび.NETの）ガベージコレクタには、頻繁にスキャンする短期メモリ領域と、あまり頻繁にスキャンしないセカンダリメモリ領域があります。Monoはこれをナーサリと呼びます。 どのオブジェクトを破棄できるかを調べるために、ルート、スタック、レジスタから始まるすべてのオブジェクトをスキャンし、参照されなくなったすべてのオブジェクトを破棄します。 私の質問は、使用中のすべてのメモリが収集ごとにスキャンされるのをどのように防ぐのですか？原則として、使用されなくなったオブジェクトを見つける唯一の方法は、すべてのオブジェクトとそのすべての参照をスキャンすることです。ただし、これにより、アプリケーションで使用されていなくても、OSがメモリをスワップアウトできなくなり、「Nursery Collection」でも実行する必要がある膨大な作業のように感じます。保育園を利用することで、彼らが多くを獲得しているとは思えません。 私は何かを見逃していますか、またはガベージコレクタは実際にすべてのオブジェクトとすべての参照をスキャンするたびにスキャンしますか？

16 algorithms  garbage-collection 

スタックベースの言語でのガベージコレクション（GC）の必要性は何ですか？ForthやRPL（HP計算機）のような言語では、ガベージコレクションが必要ですか？ 出力はスタックからポップされるので、必要はないと思います。何か不足していますか？

16 garbage-collection  stack-oriented 

mark-sweep-compactガベージコレクションアルゴリズムでは、参照グラフの一貫性が失われ、オブジェクトを指すすべての参照の値を置き換える必要があるため、オブジェクトを再配置する際に世界を停止する必要があります。 しかし、オブジェクトIDがキー、ポインターが値のハッシュテーブルがあり、参照がオブジェクトアドレスの代わりに上記のIDを指す場合、参照の修正には1つの値の変更のみが必要で、一時停止はオブジェクトの場合にのみ必要ですコピー中に書き込みが試行されます... 私の考え方に間違いはありますか？

13 algorithms  garbage-collection 

/ dev / randomはエントロピーの優れたソースであり、通常使用されるものです-少なくともJavaでGCを読んでいるように、ガベージコレクションデーモンが非決定的に実行されることは受け入れられているようです。これが正しい場合、変数/ dev / randomの代わりに、ガベージコレクションのタイミングをエントロピーのソースとして使用しないのはなぜですか？

13 random  garbage-collection 

いくつかの言語は、javaの例のために、低休止GCを導入しました。 これらのGCは、全世界を一時停止することなく、ほとんどの作業を実行できます。これは明らかに非常に難しい問題です。スレッドが変更しているときにメモリを分析する必要があるため、プロセスの開始時に使用でき、終了時には使用できなくなったデータや、ゴミのように見えるデータ参照はメモリ内で移動され、GCが探している場所には表示されませんでした。 基本的に、その背後にあるアルゴリズムは何ですか？ このトピックは本当に技術的であるため、研究論文または本当に技術的な記事のリンクは有効な回答と見なされます。

12 algorithms  low-level  garbage-collection 

Javaと.NETには、メモリを管理するすばらしいガベージコレクターと、外部オブジェクト（Closeable、IDisposable）を迅速に解放する便利なパターンがありますが、それらは単一のオブジェクトによって所有されている場合のみです。一部のシステムでは、リソースは2つのコンポーネントによって個別に消費される必要があり、両方のコンポーネントがリソースを解放するときにのみ解放される場合があります。 最新のC ++ではshared_ptr、を使用してこの問題を解決しますshared_ptr。すべてのが破棄されると、リソースが確定的に解放されます。 オブジェクト指向の非決定論的にガベージコレクションされたシステムに単一の所有者がいない高価なリソースを管理およびリリースするための文書化された実証済みのパターンはありますか？

11 java  c#  design-patterns  garbage-collection  reference-counting 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 最近、ガベージコレクションアルゴリズムについて知っているかどうかインタビューで尋ねられました。 ガベージコレクションとは何であるかは知っていましたが、開発者として心配する必要はなく、ガベージコレクタがすべてのハードワークを行っているため、ガベージコレクションアルゴリズムについて学ぶことを考えたことはありませんでした。 Java開発者はガベージコレクタアルゴリズムについて知っておくべきだと思いますか？「はい」の場合、どちらを調べる必要があるか教えてください。

11 java  interview  garbage-collection 

Windows Phone / XboxとAndroidの両方で、世代別ガベージコレクションがサポートされていません。これは多くのプログラマにとってイライラさせられます。それには正当なエンジニアリング上の理由があるように見えますが、私はそれを理解できません。 現在の携帯電話は、2001年に世代別GCを備えた.NET 1.1を実行しているデスクトップ/ラップトップよりも多くのメモリとおそらく優れたCPUを備えています。また、電話やコンソールでのマルチタスクの必要性が少なくなるため、比較的多くの空きヒープスペースがあります。 それで何が得られますか？ 編集：明確にするためのいくつかのポイント： これらのプラットフォームはアプリ専用のガベージコレクションを使用するため、私の質問はGCがサポートされない理由ではありません。私の質問は、世代別ガベージコレクションがそうではない理由についてです。 世代別GCの欠如に人々が不満を抱いている理由は、非世代別GCが非常に非効率的だからです。（つまり、バッテリーの寿命が理由ではないことを意味します。） 世代別GCのサポートがないことには、正直な技術的理由があると思います。これは修辞的な質問ではありません。

11 java  .net  android  windows-phone-7  garbage-collection 

私が見ることができることから、リソース管理には、決定論的破壊と明示的破壊という2つの一般的な形式があります。前者の例は、C ++デストラクタとスマートポインタまたはPerlのDESTROYサブです。後者の例は、Rubyのブロックから管理リソースへのパラダイムまたは.NETのIDisposeインターフェイスです。 新しい言語は後者を選択しているようです。おそらく、参照カウント以外の種類のガベージコレクションシステムを使用することの副作用としてです。 私の質問はこれです：スマートポインターまたは参照カウントガベージコレクションシステムのデストラクタ-ほとんど同じこと-が暗黙的かつ透過的なリソース破壊を可能にすることを考えると、それは明示に依存する非決定的タイプよりもリークの少ない抽象化です表記？ 具体的な例を挙げましょう。単一のスーパークラスのC ++サブクラスが3つある場合、特定の破棄を必要としない実装がある可能性があります。多分それは別の方法でその魔法をします。特別な破棄を必要としないという事実は関係ありません。すべてのサブクラスが同じように使用されます。 別の例では、Rubyブロックを使用しています。2つのサブクラスはリソースを解放する必要があるため、スーパークラスはコンストラクターでブロックを使用するインターフェースを選択します。ただし、他の特定のサブクラスは特別な破棄を必要としないため、ブロックを必要としない場合もあります。 後者はリソース破壊の実装の詳細をリークしますが、前者はリークしませんか？ 編集：たとえば、RubyとPerlの比較は、一方は確定的破壊を持ち、もう一方はそうではないため、より公平である可能性がありますが、両方ともガベージコレクションされます。

9 c++  ruby  perl  garbage-collection  smart-pointer 

2つのスレッドがあり、互いに非同期でデータメッセージを非同期に送信することによって通信するとします。各スレッドには、ある種のメッセージキューがあります。 私の質問は非常に低いレベルです。メモリを管理する最も効率的な方法として何が期待できますか？私はいくつかの解決策を考えることができます： 送信者はを介してオブジェクトを作成しますnew。受信者の呼び出しdelete。 メモリプーリング（メモリを送信者に転送するため） ガベージコレクション（Boehm GCなど） （オブジェクトが十分に小さい場合）ヒープ割り当てを完全に回避するために値でコピー 1）は最も明白なソリューションなので、プロトタイプに使用します。おそらくそれはすでに十分であるということです。しかし、私の特定の問題とは関係なく、パフォーマンスを最適化する場合、どの手法が最も有望かと思います。 特にスレッド間の情報の流れに関する追加の知識を使用できるので、プールは理論的には最高だと思います。でも、それが一番難しいのも怖いです。たくさんのチューニング... :-( ガベージコレクションは後で（ソリューション1の後）非常に簡単に追加できるはずであり、非常にうまく機能すると期待しています。したがって、1）が非効率的であることが判明した場合、それが最も実用的な解決策であると思います。 オブジェクトが小さくてシンプルな場合は、値によるコピーが最も高速な場合があります。ただし、サポートされるメッセージの実装に不必要な制限を強いることを恐れているので、避けたいと思います。

9 c++  performance  low-level  garbage-collection