GCオーバーヘッド制限を超えました

JVMが「java.lang.OutOfMemoryError：GCオーバーヘッド制限を超えました」をスローするために使用するサンプリング時間はどれくらいですか？パラメータGCTimeLimitとGCHeapFreeLimitで98％と2％を制御できることは知っていますが、サンプリング時間はどうですか？

以下からのJava SE 6 HotSpotの[TM]仮想マシンのガベージコレクションのチューニング

以下

過剰なGC時間とOutOfMemoryError

ガベージコレクションに費やされている時間が多すぎると、並行コレクターはOutOfMemoryErrorをスローします。ガベージコレクションに費やされた合計時間が98％を超え、回復されたヒープが2％未満の場合、OutOfMemoryErrorがスローされます。この機能は、ヒープが小さすぎるためにほとんどまたはまったく進行せずに、アプリケーションが長期間実行されないようにするために設計されています。必要に応じて、コマンドラインにオプション-XX：-UseGCOverheadLimitを追加して、この機能を無効にすることができます。

ポリシーは、並行収集の場合と同じですが、同時収集の実行に費やされた時間は98％の時間制限にカウントされません。つまり、アプリケーションの停止中に実行された収集のみが、過剰なGC時間にカウントされます。このようなコレクションは、通常、並行モードの失敗または明示的なコレクション要求（たとえば、System.gc（）の呼び出し）が原因です。

さらに下の通路と組み合わせて

明示的なガベージコレクションの最も一般的に使用される用途の1つは、RMIの分散ガベージコレクション（DGC）で発生します。RMIを使用するアプリケーションは、他の仮想マシンのオブジェクトを参照します。時折ローカルヒープを収集しないと、これらの分散アプリケーションでガベージを収集できないため、RMIは定期的に完全な収集を強制します。これらのコレクションの頻度は、プロパティで制御できます。例えば、

java -Dsun.rmi.dgc.client.gcInterval=3600000

-Dsun.rmi.dgc.server.gcInterval=3600000 毎分1回というデフォルトのレートではなく、毎時1回の明示的な収集を指定します。ただし、これにより、一部のオブジェクトが再利用されるまでに時間がかかる場合もあります。DGCアクティビティの適時性に上限が必要ない場合は、これらのプロパティをLong.MAX_VALUEまで高く設定して、明示的なコレクション間の時間を効果的に無限にすることができます。

98％を決定するための評価期間は1分の長さであることを示唆しているようですが、SunのJVMでは正しい定義で構成可能である可能性があります。

もちろん、他の解釈も可能です。