G1: higher perm gen footprint or a possible perm gen leak?

Srinivas Ramakrishna ysr1729 at gmail.com
Fri Jan 3 14:02:23 PST 2014


Hi Thomas --


On Fri, Jan 3, 2014 at 1:52 PM, Thomas Schatzl <thomas.schatzl at oracle.com>wrote:

> Hi,
>
> On Fri, 2014-01-03 at 11:30 -0800, Srinivas Ramakrishna wrote:
> > Thanks everyone for sharing yr experiences. As I indicated, I do
> > realize that G1 does not collect perm gen concurrently.
> > What was surprising was that G1's use of perm gen was much higher
> > following its stop-world full gc's
> > which would have collected the perm gen. As a result, G1 needed a perm
> > gen quite a bit more than twice that
> > given to parallel gc to be able to run an application for a certain
> > length of time.
>
> Maybe explained by different soft reference policies? I.e. maybe the
> input for the soft reference processing is different in both collectors,
> making it behave differently, possibly keeping alive more
> objects/classes for longer.
>

Thanks for that thought; i'll keep that in mind.


>
> > I'll provide more data on perm gen dynamics when I have it. My guess
> > would be that somehow G1's use of
> > regions in the perm gen is causing a dilation of perm gen footprint on
> > account of fragmentation in the G1 perm
> > gen regions. If that were the case, I would expect a modest increase
> > in the perm gen footprint, but it seemed the increase in
> > footprint was much higher. I'll collect and post more concrete numbers
> > when I get a chance.
>
> (G1) Perm gen is never region based.
>
>
Ah, thanks for correcting that misconception of mine. So we can cross that
off.

-- ramki


> Thomas
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20140103/996d4c42/attachment.html 


More information about the hotspot-gc-use mailing list