新しい機能を導入する複雑で大規模なマルチスレッド アプリケーションがあります。
専門的なハードウェアへの呼び出しを追加しました (ベンダー提供の JNI ライブラリ経由)。ただし、その (非常に高速な) 関数が呼び出される前に、関数に送信されるデータ構造を設定するために、いくつかの作業が事前に行われます。
ただし、アプリケーションの GC プロファイルは非常に途切れ途切れであり、これらの作成手順の一部が GC によって中断されているようです。これらのイベントの最初のイベントとハードウェア リソースへのハンドオフの間の時間を一定に保つか、可能な限り一定に保つ必要があるため、これは重要です。
世界の GC の一時停止中にこれらの操作が停止しないように、「GC の同期」と言う方法はありますか?
RHL5.5 で 64 ビット 1.7 JDK を使用する
ありがとう
実際にフル ガベージ コレクション中に問題が発生している場合、問題は、これらのフル ガベージ コレクション スイープの頻度を下げるために何ができるかです。
まず、これらの完全なスイープをトリガーする状況を分析してみてください。一般的にヒープ領域が不足していませんか? もしそうなら、なぜヒープが頻繁に不足するのですか (どこかにリークの可能性がありますか?)
また、マイナー (より高速な) ガベージ コレクション中に、オブジェクトは若い世代 (eden とサバイバー 1) からサバイバー 2 に移動されます。 Tenured に十分なスペースがある場合は、完全なスイープをトリガーします。そのため、若い世代が大きく、実行時間の長いオブジェクトが一定量ある場合、問題が発生する可能性があります。
結局のところ、それを分析する必要があります。アプリケーションのプロファイリングを行い、完全なガベージ コレクションが発生する時期と理由を特定し、アプリケーションを調整して、ガベージ コレクションの頻度を下げるか、ガベージ コレクションがいつ発生するかを「制御」できるようにします。
完全を期すために、 Real-time Java (RTSJ)を実装する JVM を使用することもできます。
リアルタイム JVM では、 GCアクティビティによって中断されることのないスレッドで、時間に敏感なタスクを実行できます。残念ながら、最近では利用できる RT JVM は多くありません。
GC の動作は決定論的ではないため、確実に同期することはできません。
次の 3 つのオプションが思い浮かびます。
とにかく、あなたのニーズに最適なオプションは、Java の代わりに真のリアルタイム言語実装を使用することです
新しい時間に敏感なタスクを構築していて、そのタスクを使用して JVM の GC 動作を修正できない場合、別のオプションとして、タスクを別の JVM に移動する ことができます。
プロセス間/マシン通信は、最小パフォーマンスが高いことを意味しますが、JNI 通信を行う別の JVM インスタンスでは、親プロセス内よりも自由に GC を調整できるため、不安定性をより細かく制御できます。