Hotspot的清除GC停止运行，只留下标记扫描GC

我在某个程序中遇到Hotspot GC的奇怪现象。有时候，看起来好像清除GC刚刚死亡，只留下标记扫描GC，而不是每次Eden空间填满。不用说，这对于性能来说太可怕了。我没有设法弄清楚这个问题发生的条件。Hotspot的清除GC停止运行，只留下标记扫描GC

现在看这个行为的JVM，老一代是170 MB（使用和最大），永远不会增长或收缩的集合，伊甸园是85 MB，幸存者空间永远不会使用任何（我认为这与GC未运行的清除GC一致），并且总分配的堆大小为256 MB（显然匹配的是Old + Eden）。

任何线索可能会导致这种情况？

来源

2011-07-09 Dolda2000

我怀疑堆太满了。如果旧的空间+伊甸园空间加起来最大的堆空间，那么就没有空间留下幸存空间，并且不能运行世代收集器。

尝试增加最大堆空间。

的一点是，必须有在生存空间（一个或多个）足够的自由空间来保存生存的伊甸园空间的集合中的所有对象。如果可用空间不可用，则复制收集器将无法工作，并且JVM必须回退以标记和扫描。

这是代/收藏家如何工作的基础。

就像我说的，尝试增加堆空间。

来源

2011-07-09 05:22:53

我忘了提及它，但幸存者空间为空时，它们的大小不为零。 VisualGC表示S0为576 kB，S1为512 kB，这比我在现场虚拟机中通常看到的要多（我现在正在查看的功能正常的有每个448 kB的生存空间）。鉴于此，是否可以解释依然成立？诚然，伊甸园和老城区的空间与分配的空间一样大，但是应该阻止Scavenge GC运行？ – Dolda2000

你当然看起来是对的，但那确实让我想知道当时真的发生了什么。当伊甸园空间充满时，幸存者或老旧空间中没有足够的空间，伊甸园空间中的静物仍在何处？显然，JVM不会抛出OutOfMemoryException或其他任何东西。伊甸园的空间是否简单紧凑？ – Dolda2000

*“伊甸园的空间是否简单紧凑？”* - 我认为是。还有什么其他的选择？无论如何，最好的想法是首先避免陷入这种情况。 –

Hotspot的清除GC停止运行，只留下标记扫描GC

回答

相关问题