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

Cのような言語では、プログラマはfreeへの呼び出しを挿入することが期待されています。コンパイラがこれを自動的に行わないのはなぜですか？人間は（バグを無視して）妥当な時間内にそれを行うので、不可能ではありません。 EDIT：今後の参考のために、ここで興味深い例があり、別の議論です。

63 compilers  memory-management  garbage-collection 

典型的な世代別ガベージコレクタは、最近割り当てられたデータを別のメモリ領域に保持します。典型的なプログラムでは、多くのデータは短命であるため、若いガベージ（マイナーGCサイクル）を頻繁に収集し、古いガベージを頻繁に収集しないことは、メモリオーバーヘッドとGCの実行時間の適切な妥協点です。 直感的には、若いリージョンのデータに頻繁にアクセスし、すべてを1か所に保持するため、キャッシュに対するメインメモリの待機時間比率が増加すると、単一リージョンコレクターと比較した世代別ガベージコレクターの利点が大きくなります。実験結果はこの直感を裏付けていますか？

38 programming-languages  computer-architecture  cpu-cache  garbage-collection 

ガベージコレクションされた言語設計に関する決定についての洞察を探しています。おそらく、言語の専門家が私を啓発できるでしょうか？私はC ++のバックグラウンドを持っているので、この領域は私を困惑させます。 Ruby、Javascript / ES6 / ES7、Actionscript、LuaなどのOOPyオブジェクトをサポートするほとんどすべてのガベージコレクション言語は、デストラクタ/ファイナライズパラダイムを完全に省略しているようです。Pythonは、そのclass __del__()メソッドを持つ唯一のものであるようです。どうしてこれなの？オブジェクトのデストラクタ/ファイナライズメソッドの効果的な実装を妨げる自動ガベージコレクションを使用する言語には、機能的/理論的な制限がありますか？ これらの言語がメモリを管理する価値のある唯一のリソースと見なしていることは非常に欠けていると思います。ソケット、ファイルハンドル、アプリケーションの状態はどうですか？オブジェクトファイナライズの非メモリリソースと状態をクリーンアップするカスタムロジックを実装する機能がない場合、アプリケーションにカスタムmyObject.destroy()スタイルの呼び出しを散らかし、クリーンアップロジックを「クラス」の外に配置し、カプセル化を中断し、 gcによって自動的に処理されるのではなく、人的エラーによるリソースリークへのアプリケーション。 これらの言語がオブジェクト破棄のカスタムロジックを実行する方法を持たないことにつながる言語設計の決定は何ですか？正当な理由があると想像しなければなりません。これらの言語がオブジェクトの破壊/最終化をサポートしなくなった技術的および理論的な決定をよりよく理解したいと思います。 更新： おそらく私の質問を表現するより良い方法： なぜ言語には、カスタムインスタンス化（コンストラクター）とともにクラスまたはクラスに似た構造を持つオブジェクトインスタンスの組み込みコンセプトがありますが、完全に破棄/ファイナライズ機能を省略しますか？自動ガベージコレクションを提供する言語は、オブジェクトが使用されなくなったときに100％の確実性でわかるように、オブジェクトの破壊/最終化をサポートする主要な候補のようです。しかし、これらの言語のほとんどはサポートしていません。 私は、デストラクタが呼び出されることは決してないだろうとは思わない。それは、gcsが回避するように設計されているコアメモリリークだからだ。デストラクタ/ファイナライザは、将来の不確定な時間まで呼び出されないかもしれないが、JavaまたはPythonが機能をサポートするのを止めなかったという議論を見ることができました。 オブジェクトのファイナライズをサポートしない理由は、言語設計の中核となる理由は何ですか？

27 programming-languages  memory-management  garbage-collection  language-design 

それで、ガベージコレクターがどのように機能するかを考えていて、興味深い問題を考えました。おそらく、ガベージコレクターはすべての構造を同じ方法で走査する必要があります。彼らは、リンクリストやバランスの取れたツリーなどを横断している天気を知ることができません。また、検索でメモリを使い果たすこともできません。1つの可能な方法、およびALL構造をトラバースする唯一の方法は、バイナリツリーの場合と同じようにすべて再帰的にトラバースすることです。ただし、これにより、リンクリストまたは単にバランスの悪いバイナリツリーでスタックオーバーフローが発生します。しかし、私が今まで使用したガベージコレクション言語はすべて、このようなケースに対処するのに問題がないようです。 ドラゴンブックでは、「スキャンされていない」種類のキューを使用しています。基本的に、構造を再帰的にトラバースするのではなく、キューとしてマークする必要があるものを追加し、最後にマークされていないものごとに削除します。しかし、このキューは非常に大きくなりませんか？ それでは、ガベージコレクタはどのように任意の構造をトラバースしますか？このトラバーサル技術はどのようにオーバーフローを回避しますか？

23 programming-languages  memory-management  garbage-collection 

ガベージコレクションは、再生可能なメモリを見つけるために、生きているすべてのオブジェクトを訪問する必要があります。（多くの世代がこれを少し遅らせることで） すべてが同じであるため、他のブロックをページインしてからページアウトする前に、すでにRAMにページングされているオブジェクトを最初に訪問することをお勧めします。 もう1つの可能性は、OSがプロセスからラムのページを取り去ろうとするとき、ページアウトする必要なく放棄できるページがあるかどうか、GCが最初に尋ねられることです。GCはほとんどの場合、ページからオブジェクトを移動することで実行されるため、OSがページを必要とする時間制限内にそのページをクリアできます。 それでも、GCが機能する順序を決定するOSページングシステムと統合されているガベージコレクターは思い出せません。

12 memory-management  paging  garbage-collection 

手動のメモリ管理にうんざりしているようで、ガベージコレクションを発明し、生活はかなり良かったです。しかし、他のすべてのリソースタイプはどうですか？ファイル記述子、ソケット、またはデータベース接続などのユーザー作成データですか？ これは素朴な質問のように思えますが、誰かが質問した場所はどこにもありません。ファイル記述子について考えてみましょう。プログラムが起動時にのみ4000 fdsを使用できるようになることをプログラムが知っているとします。ファイル記述子を開く操作を実行するときはいつでも、 間もなく実行されることを確認してください。 そうであれば、ガベージコレクターをトリガーして、大量のメモリを解放します。 解放されたメモリの一部がファイル記述子への参照を保持していた場合は、それらをすぐに閉じます。リソースに関連付けられているメモリは、最初に開かれたときに、より適切な用語がないため、「ファイル記述子レジストリ」に登録されていたため、メモリはリソースに属していることがわかります。 新しいファイル記述子を開き、それを新しいメモリにコピーし、そのメモリ位置を「ファイル記述子レジストリ」に登録して、ユーザーに返します。 したがって、リソースはすぐには解放されませんが、リソースが完全に使用されていない場合、少なくともリソースがなくなる直前に、gcが実行されるたびに解放されます。 そして、それは多くのユーザー定義のリソースクリーンアップ問題には十分だと思われます。私はここで、リソースへの参照を含むスレッドでC ++でこれと同様のクリーンアップを実行することを参照する単一のコメントを見つけ、単一の参照のみが残っている場合に（クリーンアップスレッドから）クリーンアップしますが、これがライブラリまたは既存の言語の一部であることの証拠を見つけます。

12 garbage-collection  resource-allocation 

「Swiftはクラシック（トレース）GCを実行せず、ARCを使用する」と聞くことがあります。 しかし、参照カウントを必要とするSwiftセマンティクスに何かがあるかどうかはわかりません。トレースGCを使用するために、独自のSwiftコンパイラーとランタイムを構築できるようです。 それでは、Swiftについて正確に「参照カウント」とは何ですか？Appleの実装または言語自体？言語自体にそのラベルを使用できるほどARCを強力にサポートする言語またはライブラリの一部はありますか？

9 semantics  garbage-collection 

手動のメモリ管理を備えたプログラミング言語があるとします。正確なガベージコレクションを、基本的な言語構成要素としてではなく、ライブラリとして実装できるようにするために、この言語にはどのような機能が必要ですか？ 正確なGCとは、ヒープへのポインタのみがトラバースされ、どの変数が有効であるかどうかを確認することを意味します。 その他の考慮事項： CとC ++にはBoehmガベージコレクターがありますが、正確なGCではないため、これはカウントしません。Boehmコレクターは、スタック上でポインターである可能性のあるものはすべて、純粋にメモリー調整要件に基づいているものをポインターであると想定しています。たとえば、ポインタは4バイト境界で整列する必要があるため、ポインタのようにビットレベルkで(k % 4) == 0見える整数。 カササギは、正確なガベージコレクターを使用するように既存のCコードを変換します。生成されたCコードには、ガベージコレクション用の多くのスタブがあります。つまり、コレクターを使用してスタックポインターをヒープに登録するためのものです。誰もそのようにコードを書くことは期待できないので、私はこれを数えません。これは、他の言語のコンパイルターゲットの詳細です。 そのような言語には次のものが必要だと思います。 マクロまたは何らかの形のメタプログラミング。GCルートの登録などを行うために必要なすべての追加コードをカプセル化します。 構造体または共用体を検査できる反射メカニズム。どのメンバーがポインターであるかを判別する必要があります。 スタックフレームのレイアウトを確認できる反射メカニズム。これは2よりもはるかに難しいようです。 これが漠然としたり、意見に基づくものではないことを願っていますが、しばらくの間、それについて疑問に思っていました。

8 memory-management  language-design  garbage-collection 

私は自分の言語に適したガベージコレクション手法を探していて、このペーパーを見つけました。ベンジャミンゴールドバーグは、厳密に型指定された言語のガベージコレクション手法について説明しているため、実行時の型情報の必要性がありません。 簡単に言えば、これは、コンパイルされたコードに直接、関数呼び出しの直後にガベージコレクション関数へのポインターを置くことによって行われます。次に、これを拡張して、MLのようなパラメトリック多態性をサポートします。 今私の質問：このテクニックをオブジェクト指向言語でどのように実装できるかについての作業はありましたか？仮想テーブルのポインタを使用した間接呼び出しを通じて多くの機能が実装されていますか？

7 programming-languages  compilers  memory-management  empirical-research  garbage-collection