Javaにはあるのに、CやC ++などの言語にガベージコレクションがないのはなぜですか？[閉まっている]

まあ、Cにはmalloc / free、C ++にはメモリ管理にnew / using-a-de-structorのようなものがあることは知っていますが、ユーザーがこれらの言語に「新しい更新」がないのはなぜだろうメモリを手動で管理するオプションがありますか、またはシステムが自動的にメモリを管理するオプションがあります（ガベージコレクション）。

やや新しい質問ですが、CSに約1年しかいません。

ガベージコレクションには、割り当ての追跡や参照カウントのためのデータ構造が必要です。これらにより、メモリ、パフォーマンス、および言語の複雑さがオーバーヘッドになります。C ++は「金属に近い」ように設計されています。つまり、利便性機能とのトレードオフよりもパフォーマンスの面を重視しています。他の言語では、トレードオフが異なります。これは、言語を選択する際の考慮事項の1つです。

とは言っても、かなり軽量でパフォーマンスの高いC ++の参照カウントには多くのスキームがありますが、それらは言語自体の一部ではなく、商用およびオープンソースの両方のライブラリにあります。オブジェクトの有効期間を管理するための参照カウントは、ガベージコレクションと同じではありませんが、同じ種類の問題の多くに対処し、C ++の基本的なアプローチにより適しています。

厳密に言えば、C言語にはメモリ管理はまったくありません。malloc（）およびfree（）は言語のキーワードではなく、ライブラリから呼び出される関数にすぎません。malloc（）とfree（）はC標準ライブラリの一部であり、Cの標準に準拠した実装によって提供されるため、この区別は今では教訓的かもしれませんが、これは過去には必ずしも当てはまりませんでした。

メモリ管理の標準がない言語が必要なのはなぜですか？これは、「ポータブルアセンブリ」としてCの起源に戻ります。特殊なメモリ管理技術の恩恵を受けたり、必要とするハードウェアやアルゴリズムの多くのケースがあります。私の知る限り、Javaのネイティブメモリ管理を完全に無効にして独自のメモリ管理に置き換える方法はありません。これは、一部の高性能/最小リソースの状況では受け入れられません。Cは、プログラムが使用するインフラストラクチャを正確に選択するためのほぼ完全な柔軟性を提供します。支払われる代償は、C言語は、バグのない正しいコードを書くのにほとんど役に立たないということです。

本当の答えは、安全で効率的なガベージコレクションメカニズムを作成する唯一の方法は、不透明な参照を言語レベルでサポートすることです。（または、逆に、直接メモリ操作に対する言語レベルのサポートの欠如。）

JavaとC＃には、操作できない特別な参照型があるため、これを行うことができます。これにより、ランタイムは、割り当てられたオブジェクトをメモリ内で移動するなどのことを自由に行うことができます。これは、高性能GCの実装に不可欠です。

記録に関しては、現代のGC実装では参照カウントを使用していないため、完全に赤いニシンです。最新のGCは世代別コレクションを使用します。この場合、新しい割り当ては、C ++のような言語のスタック割り当てと本質的に同じ方法で処理されます。のオブジェクトの割り当てが一度に解除されます。

このアプローチには長所と短所があります：利点は、GCをサポートする言語でのヒープ割り当てがGCをサポートしない言語でのスタック割り当てと同じくらい速いことであり、欠点はどちらかを破棄する前にクリーンアップを実行する必要があることです別のメカニズム（C＃のusingキーワードなど）が必要です。そうでない場合、クリーンアップコードは非決定的に実行されます。

高性能GCの鍵の1つは、特別なクラスの参照に対する言語サポートが必要であることに注意してください。Cはこの言語をサポートしておらず、今後もサポートしません。C ++には演算子のオーバーロードがあるため、GCのポインター型をエミュレートできますが、慎重に行う必要があります。実際、MicrosoftがCLR（.NETランタイム）の下で実行するC ++の方言を発明したときFoo^、「C ++スタイルの参照」と区別するために、「C＃スタイルの参照」の新しい構文を考案する必要がありました。 （例Foo&）。

C ++には、C ++プログラマーが定期的に使用しているのは、実際には単なる参照カウントメカニズムであるスマートポインターです。参照カウントは「真の」GCとは見なしませんが、手動メモリ管理や真のGCよりもパフォーマンスが低下するという犠牲を払って、決定的な破壊という利点があるにもかかわらず、多くの同じ利点を提供します。

結局のところ、答えは本当に言語設計機能に帰着します。Cは1つの選択を行い、C ++はほとんどの目的に十分な代替手段を提供しながらCとの下位互換性を可能にする選択を行い、JavaとC＃はCとの互換性はないがほとんどの目的。残念ながら、特効薬はありませんが、さまざまな選択肢に精通していれば、現在作成しようとしているプログラムに適した選択肢を選択できます。

なぜなら、C ++のパワーを使用する場合、必要がないからです。

ハーブサッター：「長年、削除を書いたことはありません。」

最新のC ++コードの記述： 21 : 10でのC ++の進化を参照してください。

多くの経験豊富なC ++プログラマを驚かせるかもしれません。

「すべて」のガベージコレクターは、メモリ内に参照されていないオブジェクトがあるかどうか、およびそれらが削除されているかどうかを定期的に確認するプロセスです。（はい、これは非常に単純化しすぎです）。これは言語のプロパティではなく、フレームワークのプロパティです。

- CおよびC ++のために書かれたガベージコレクタがあります。この1例は。

言語に「追加」されていない理由の1つは、メモリを管理するために独自のコードを使用するため、決して使用しない既存のコードの膨大な量が原因である可能性があります。別の理由として、CおよびC ++で記述されたタイプのアプリケーションは、ガベージコレクションプロセスに関連するオーバーヘッドを必要としない可能性があります。

Cは、ガベージコレクションがほとんど選択肢にならない時代に設計されました。また、ガベージコレクションが通常機能しない場合の使用を目的としていました-最小限のメモリと最小限のランタイムサポートを備えたベアメタルのリアルタイム環境。Cは最初のUNIXの実装言語であり、64 * K *バイトのメモリを備えたpdp-11上で実行されたことを思い出してください。C ++はもともとCの拡張でした-選択はすでに行われており、ガベージコレクションを既存の言語に移植するのは非常に困難です。1階から組み込まなければならないものです。

正確な引用符はありませんが、BjarneとHerb Sutterの両方が次のように述べています。

C ++にはガベージコレクターは必要ありません。ガベージコレクターはガベージがないためです。

最新のC ++では、スマートポインターを使用するため、ゴミがありません。

オプションのガベージコレクタを含めるためにこれらの言語が更新されていない理由を尋ねます。

オプションのガベージコレクションの問題は、異なるモデルを使用するコードを混合できないことです。つまり、ガベージコレクターを使用していることを前提とするコードを記述した場合、ガベージコレクションがオフになっているプログラムでは使用できません。あなたがそうするなら、それはどこにでも漏れます。

ガベージコレクションを使用した言語でデバイスハンドラを記述することを想像できますか？GCの実行中に何ビットがラインに届くでしょうか？

またはオペレーティングシステム？カーネルを起動する前に、ガベージコレクションの実行を開始するにはどうすればよいですか？

Cは、ハードウェアタスクに近い低レベル用に設計されています。問題？それは非常に素晴らしい言語であり、多くの高レベルのタスクにも適しています。言語皇帝はこれらの使用法を認識していますが、デバイスドライバー、組み込みコード、およびオペレーティングシステムの要件を優先度としてサポートする必要があります。

この質問に対する簡潔で退屈な答えは、ガベージコレクターを作成する人々のために、ガベージコレクションされていない言語が必要であるということです。それは同時に、メモリレイアウトを非常に正確に制御することができます言語持っている概念的に簡単ではありませんし、上で実行されているGCを持っています。

もう1つの質問は、CおよびC ++にガベージコレクターがない理由です。まあ、私はC ++がそれらのいくつかを持っていることを知っていますが、そもそもGCで処理されるように設計されていない言語と、この時代は、GCを見逃すようなものではありません。

また、GCを古いGC以外の言語に追加する代わりに、GCをサポートしながらほとんど同じ構文を持つ新しい言語を実際に作成する方が簡単です。JavaとC＃はこの良い例です。

など、さまざまな問題があります...

• GCはC ++の前に、おそらくCの前に発明されましたが、GCが実際に広く受け入れられる前にCとC ++の両方が実装されました。
• 基礎となる非GC言語がなければ、GC言語とプラットフォームを簡単に実装することはできません。
• GCは、典型的なタイムスケールなどで開発された典型的なアプリケーションコードに対して非GCよりも明らかに効率的ですが、より多くの開発努力がトレードオフであり、特殊なメモリ管理が汎用GCよりも優れているという問題があります。それに加えて、C ++は通常、追加の開発作業がなくても、ほとんどのGC言語よりも明らかに効率的です。
• GCは、C ++スタイルのRAIIよりも一般的に安全ではありません。RAIIでは、基本的に信頼性が高くタイムリーなデストラクタがサポートされているため、メモリ以外のリソースを自動的にクリーンアップできます。これらは、参照サイクルに問題があるため、従来のGCメソッドと組み合わせることはできません。
• GC言語には、特有の種類のメモリリークがあります。特に、再び使用されることのないメモリに関連していますが、既存の参照が存在し、nullアウトまたは上書きされたことはありません。明示的にこれを行う必要性は、原則的に、deleteまたはfree明示的に行う必要性と同じです。GCアプローチにはまだ利点があります-ぶら下がり参照はありません-静的解析はいくつかのケースをキャッチできますが、すべてのケースに完璧なソリューションはありません。

基本的に、部分的には言語の年齢についてですが、とにかく非GC言語の場所は常にあります-たとえそれがちょっとニチャイの場所であっても。そして真剣に、C ++では、GCの欠如は大したことではありません-あなたのメモリは異なって管理されますが、管理されていません。

Microsoftが管理するC ++には、同じアプリケーションでGCと非GCを混在させる機能が少なくともいくつかあり、それぞれの利点を組み合わせて使用​​できますが、実際にこれがどの程度うまく機能するかを経験することはできません。

私の関連する回答への担当者リンク...

• https://stackoverflow.com/questions/1529679/how-do-you-program-safely-outside-of-a-managed-code-environment/1529731#1529731
• https://stackoverflow.com/questions/1424660/garbage-collection-vs-non-garbage-collection-programming-languages/1496547#1496547
• https://stackoverflow.com/questions/4984849/why-circular-referenced-objects-with-del-defined-are-uncollectable-in-python/4984934#4984934
• https://stackoverflow.com/questions/5009869/how-to-implement-garbage-collection-in-c/5009984#5009984

ガベージコレクションは、DMA対応ハードウェアのドライバーの開発に使用されるシステム言語と基本的に互換性がありません。

オブジェクトへの唯一のポインタが周辺機器のハードウェアレジスタに格納されることは完全に可能です。ガベージコレクターはこれを知らないため、オブジェクトが到達不能であると判断し、収集します。

この引数は、GCを圧縮するためにdoubleを保持します。ハードウェアペリフェラルで使用されるオブジェクトへのメモリ内参照を慎重に維持したとしても、GCがオブジェクトを再配置したとき、ペリフェラル構成レジスタに含まれるポインタを更新する方法がわかりません。

そのため、固定DMAバッファーとGC管理オブジェクトの混合が必要になります。つまり、両方の欠点がすべてあります。

なぜなら、C＆C ++は、たとえば、組み込みシステムで1MBのメモリを搭載した16ビットプロセッサで実行するための汎用目的の比較的低レベルの言語であり、gcでメモリを浪費する余裕がないためです。

C ++とCにはガベージコレクターがあります。Cでこれがどのように機能するかはわかりませんが、C ++ではRTTIを利用してオブジェクトグラフを動的に検出し、ガベージコレクションに使用できます。

私の知る限り、ガベージコレクタなしでJavaを記述することはできません。ちょっとした検索でこれが判明しました。

JavaとC / C ++の主な違いは、C / C ++では常に選択できるのに対して、Javaでは多くの場合設計上のオプションがないことです。

パフォーマンスと安全性のトレードオフです。

ガベージがJavaで収集されるという保証はないため、長い間スペースを使い果たしている可能性がありますが、参照されていないオブジェクト（つまり、ガベージ）のスキャンは、未使用のオブジェクトを明示的に削除または解放するよりも時間がかかります

利点は、もちろん、ポインタやメモリリークなしで言語を構築できることです。そのため、正しいコードを生成する可能性が高くなります。

これらの議論には、時々「宗教的」な縁があるかもしれません-注意してください！

以下に、Cのようなシステム言語で使用できないGC固有の問題のリストを示します。

• GCは、オブジェクトを管理するコードのレベル以下で実行する必要があります。カーネルにはそのようなレベルはありません。

• GCは時々マネージコードを停止する必要があります。次に、カーネルにそれを実行するとどうなるかを考えます。マシン上のすべての処理は、たとえば1ミリ秒間停止しますが、GCは既存のメモリ割り当てをすべてスキャンします。これは、厳しいリアルタイム要件の下で動作するシステムを作成するすべての試みを殺すでしょう。

• GCは、ポインターと非ポインターを区別できる必要があります。つまり、存在するすべてのメモリオブジェクトを確認し、そのポインタが見つかるオフセットのリストを作成できる必要があります。

  この発見は完璧でなければなりません。GCは発見したすべてのポインタを追跡できなければなりません。誤検知を逆参照すると、クラッシュする可能性があります。偽陰性の発見に失敗した場合、まだ使用中のオブジェクトが破壊され、マネージコードがクラッシュしたり、データが静かに破損したりする可能性があります。

  これには、存在するすべてのオブジェクトに型情報を保存することが絶対に必要です。ただし、CとC ++はどちらも、型情報を含まない単純な古いデータオブジェクトを許可します。

• GCは本質的に遅いビジネスです。Javaでソーシャル化されたプログラマーはこれに気付かないかもしれませんが、Javaで実装されていない場合、プログラムは桁違いに速くなる可能性があります。また、Javaを遅くする要因の1つはGCです。これは、JavaのようなGC化された言語がスーパーコンピューティングで使用されることを妨げるものです。マシンの消費電力が年間100万ドルの場合、ガベージコレクションにその10％を支払う必要はありません。

CおよびC ++は、考えられるすべてのユースケースをサポートするために作成された言語です。そして、ご覧のとおり、これらのユースケースの多くはガベージコレクションによって除外されています。したがって、これらのユースケースをサポートするために、C / C ++はガベージコレクションできません。