GC-- PSYoungGen

[Srinivas Ramakrishna]

[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> 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/7c020bb0/attachment.htm>