GC-- PSYoungGen

[Charlie Hunt]

Hi Ramki,

Very nice explanation!

Thanks for documenting & sharing. :-)

charlie ....

On Aug 8, 2012, at 12:15 PM, Srinivas Ramakrishna wrote:

[note: subject line corrected since this is unrelated to the thread in which it was posted]

Hi Kirk --

This is called a promotion failure, and causes the scavenge to be unwound and followed up with a major collection of the whole heap.
The "apparent" increase in heap usage is because some objects got copied into the old and survivor spaces, but the scavenge could not
complete because it ran out of space to store further survivors from the young gen. The "unwinding" step does not claim back the space
freed up by the previous copying step so looks like an increase in heap usage. I'd ignore the "after" size for such failed scavenges, which are
denoted in the logs with the GC-- notation. The "--" indicates a failure of the scavenge mid-way. (Aside: I don't think the PrintGCStats script does that,
so it would often show up as an unexplained increase in the heap size after the failed scavenge. This is a shortcoming of the script that
can and should be fixed.)

There are situations where the GC will not even attempt a scavenge based on recent promotion volume history and current space
available in the old gen. This was not such a case -- in such cases, you will just see a full gc occur straightaway without a
scavenge having been attempted -- in general the PSScavenge collector looks ahead one scavenge and will often invoke first
a scavenge and immediately follow that up with a full gc cycle because it believes that the next scavenge would not succeed.
If there is a sudden phase change or if the promotion volume is bursty, that look-ahead may sometimes be confounded and can
both be either too conservative, causing a major cycle before it might be strictly necessary, or sometimes fail to cause a major cycle
soon enough and run into a promotion failure, such as happened below for you.

-- ramki

On Wed, Aug 8, 2012 at 4:56 AM, Kirk Pepperdine <kirk at kodewerk.com<mailto:kirk at kodewerk.com>> wrote:
Hi,

I'm looking at this record.

919.673: [GC-- [PSYoungGen: 643582K->643582K(648704K)] 1905561K->2004508K(2014080K), 0.0319900 secs]

This implies that there are +98947K bytes consumed during the collection. However, this is a STW collection implying that the source of the heap consumption is the garbage collector it's self which implies that objects are copied and then removed from young gen. If so, does this mean that there is a failure in that the VM have recognized that heap occupancy was @ 94.6% prior to the collection implying that is was very likely that tenured would be flooded by scavenge?

Regards,
Kirk



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120808/281c2b75/attachment.htm>