特定のプログラムでホットスポットのGCで変なことが起こっています。時には、まるで掃気GCがちょうど死んでいるように見え、EdenスペースがいっぱいになるたびにマークスイープGCだけが走っているようです。言うまでもなく、これはパフォーマンスにとって恐ろしいことです。私はこの問題が発生する条件を把握することができませんでした。ホットスポットのGCが実行を停止し、マークスイープGCのみが残る
現在のところ、この現象が発生しているJVMを見ると、旧世代は170 MB(使用済みおよび最大)であり、コレクション全体で拡大または縮小することはなく、Eden Genは85 MBであり、Survivorスペースは決して使用されません私は推測するとGCが動作していないスカベンジと一致しています)、割り当てられたヒープサイズの合計は256 MBです(明らかにOld + Edenと一致します)。
これを引き起こす可能性のある手がかりはありますか?
私はそれを言い忘れましたが、生き残りスペースは空ですが、サイズはゼロではありません。 VisualGCによると、S0は576 kB、S1は512 kBで、ライブVMで通常見られる以上のものです(私が今見ている適切な機能は、それぞれ448 kBのサバイバースペースを持っています)。説明はまだ成り立ちますか? Eden空間とOld Gen空間の両方が割り当てられているものと同じ大きさですが、Scavenge GCが実行されないようにする必要があります。 – Dolda2000
あなたは確かに正しいと思われますが、それは本当にその時に何が起こるのか疑問に思っています。エデンの空間が満ちていて、生存者や旧世代の空間に十分なスペースがない場合、エデンの空間でまだ生きているオブジェクトはどこに行きますか?明らかに、JVMはOutOfMemoryExceptionなどをスローしません。エデンスペースは単純に圧縮されていますか? – Dolda2000
* "エデンスペースは単純に圧縮されていますか?" * - そうだと思います。他に何がありますか?とにかく、最善の考え方は、まずその状況に陥るのを避けることです。 –