java - ガベージコレクター（.net / java）はリアルタイムシステムの問題ですか？

Question

非常に一貫して高速に応答する必要があるシステムを構築する場合、ガベージコレクターに潜在的な問題がありますか？

何年も前のホラーストーリーを覚えています。典型的な例は、ガベージコレクターがクリーンアップを行うときに、ジャンプの途中でキャラクターが数秒間停止するアクションゲームでした。

数年先ですが、まだまだ問題なのかと思います。.Net 4の新しいガベージコレクターについて読みましたが、それでも大きなブラックボックスのように見え、すべてがうまくいくと信じる必要があります。

常に迅速に対応する必要のあるシステムがあり、ガベージコレクターの問題が大きすぎる場合は、よりハードコアなものを選択して、C++のような言語で自分で制御する方がよいでしょうか。問題が判明した場合、ランタイムの新しいバージョンを待つか、コレクターに影響を与えるために非常に奇妙なことをする以外に、基本的にほとんど何もできないことを嫌います。

編集

すべての素晴らしいリソースに感謝します。ただし、ほとんどの記事/カスタムgc/ソリューションはJava環境に関連しているようです。.Netには、カスタムGCのチューニング機能やオプションもありますか？

Answer 1

正確には、ガベージコレクターはリアルタイムシステムの問題です。さらに正確に言うと、自動メモリ管理機能を備えた言語でリアルタイムソフトウェアを作成することができます。

詳細については、Javaを使用してリアルタイム動作を実現するためのアプローチの1つについて、Javaのリアルタイム仕様を参照してください。RTSJの背後にある考え方は非常に単純です-ヒープを使用しないでください。RTSJは、スレッドがいかなる種類のヒープメモリにもアクセスしないようにする新しい種類のRunnableオブジェクトを提供します。スレッドは、スコープ付きメモリ（ここでは異常なことはありません。スコープを閉じると値が破棄されます）または不滅のメモリ（アプリケーションの存続期間を通じて存在する）のいずれかにアクセスできます。不滅のメモリ内の変数は、何度も何度も新しい値で書き込まれます。

RTSJは、不滅のメモリを使用することで、スレッドがヒープにアクセスしないようにします。さらに重要なことに、システムには、スレッドによるプログラムの実行をプリエンプトするガベージコレクタがありません。

詳細については、JPLとSunが発行した論文「ProjectGolden Gate：Towards Real-Time JavainSpaceMissions」を参照してください。

Answer 2

私はJavaと.NETでゲームを作成しましたが、これが大きな問題になることはありませんでした。あなたの「ホラーストーリー」は、何年も前のガベージコレクターに基づいていると思います。それ以来、テクノロジーは本当に長い道のりを歩んできました。

ガベージコレクションに基づいてJava/.NETを使用することを躊躇するのは、ハードリアルタイム制約（モーションコントローラーなど）を使用した組み込みプログラミングのようなものだけです。

ただし、GCの一時停止に注意する必要があります。次のすべてが、GCの一時停止のリスクを最小限に抑えるのに役立ちます。

• 新しいオブジェクトの割り当てを最小限に抑える-最新のGCシステムではオブジェクトの割り当ては非常に高速ですが、将来の一時停止に寄与するため、最小限に抑える必要があります。オブジェクトの配列の事前割り当て、オブジェクトプールの保持、ボックス化されていないプリミティブの使用などの手法を使用できます。
• 頻繁に使用される関数やデータ型には、 Javalutionなどの特殊な低レイテンシライブラリを使用してください。これらは、リアルタイム/低遅延アプリケーション用に特別に設計されています
• 複数のバージョンが利用可能な場合は、最適なGCアルゴリズムを使用していることを確認してください。低遅延アプリケーション向けのSunG1Collectorについて良いことを聞いたことがあります。最高のGCシステムは、ほとんどのコレクションを同時に実行するため、ガベージコレクションは、たとえあったとしても、非常に長い間「世界を止める」必要はありません。
• GCパラメータを適切に調整します。通常、全体的なパフォーマンスと一時停止時間の間にはトレードオフがあります。前者を犠牲にして後者を改善することをお勧めします。

あなたが非常に金持ちなら、もちろんハードウェアGCサポート付きのマシンを購入することができます。:-)

Answer 3

はい、ガベージはリアルタイムシステムで決定論的な方法で処理する必要があります。

1つのアプローチは、各メモリ割り当て中に一定量のガベージコレクション時間をスケジュールすることです。これは「作業ベースのガベージコレクション」と呼ばれます。リークがない場合、割り当てと収集は比例する必要があるという考え方です。

もう1つの簡単なアプローチ（「時間ベースのガベージコレクション」）は、定期的なガベージコレクションが必要かどうかに関係なく、一定の割合の時間をスケジュールすることです。

いずれの場合も、完全なガベージコレクションを実行するのに十分な時間を費やすことが許可されていないため、プログラムが使用可能なメモリを使い果たす可能性があります。これは、ごみを収集するために必要な限り一時停止することが許可されている非リアルタイムシステムとは対照的です。

Answer 4

理論的な観点からは、ガベージコレクターは問題ではなく解決策です。動的メモリ割り当てがある場合、リアルタイムシステムは困難です。特に、通常のC関数は、リアルタイムの保証を提供malloc()しfree()ません（通常は高速ですが、少なくとも理論的には、過度の時間を使用する「最悪のケース」があります）。

リアルタイム保証を提供する動的メモリアロケータを構築することは可能ですが、これにはアロケータがいくつかの重い作業、特にRAM内のいくつかのオブジェクトの移動を行う必要があります。オブジェクトの移動は、ポインターを調整することを意味し（透過的に、アプリケーションコードの観点から）、その時点で、アロケーターはガベージコレクターからわずか1歩離れています。

通常のJavaまたは.NETの実装では、応答時間が保証されているという意味でリアルタイムのガベージコレクションは提供されませんが、GCは依然として高度に最適化されており、ほとんどの場合、応答時間が非常に短くなっています。通常の状態では、非常に短い平均応答時間は、保証された応答時間よりも優れています（「保証された」は「速い」を意味しません）。

また、通常のJavaまたは.NETの実装は、リアルタイムではないオペレーティングシステムで実行され（OSは他のスレッドをスケジュールするか、一部のデータをスワップファイルに積極的に送信するかなど）、どちらもそうではないことに注意してください。基盤となるハードウェア（たとえば、一般的なハードディスクでは、「再キャリブレーションが一時停止」する場合があります）。ハードウェアによる時折のタイミンググリッチを許容する準備ができている場合は、（慎重に調整された）JVMガベージコレクターで問題ないはずです。ゲームでも。

Answer 5

それは潜在的な問題ですが...

また、OSが過負荷のハードディスクからメモリのページを取得しているときに、C++プログラムの途中でキャラクターがフリーズする可能性があります。具体的なパフォーマンス保証を提供するように設計されたハードウェアでリアルタイムOSを使用していない場合、パフォーマンスが保証されることはありません。

より具体的な回答を得るには、特定の仮想マシンの特定の実装について質問する必要があります。ガベージコレクションに関する適切なパフォーマンス保証が提供されている場合は、ガベージコレクションされた仮想マシンをリアルタイムシステムに使用できます。

Answer 6

あなたはそれが問題であるに違いない。低レイテンシのアプリケーションを作成している場合、ほとんどのガベージコレクターが課すストップザワールドの一時停止を行う余裕はありません。JavaではGCをオフにできないため、ごみを出さないことが唯一の選択肢です。これは、オブジェクトプーリングとブートストラップを介して実行できます。これについて詳しく話しているブログ記事を書きました。

Answer 7

当社は、とりわけフィールドバスネットワークを介してバイナリセンサーを監視する大規模な.Netベースのソフトウェアアプリケーションを採用しています。状況によっては、センサーが短時間（300ミリ秒）だけアクティブになりますが、イベントを見逃すと制御対象システムがすぐに失敗するため、ソフトウェアはこれらのイベントをキャプチャする必要があります。最近、ガベージコレクターが長時間（最大1秒）実行されているために、お客様のサイトで問題が増加していることがわかりました。ガベージコレクターに時間制限を適用する方法をまだ模索中です。この短編小説の結論として、ガベージコレクターはタイムクリティカルなアプリケーションのハンディキャップだと思います。