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

Fri Jan 3 11:30:47 PST 2014

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.

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.

-- ramki

On Fri, Jan 3, 2014 at 10:05 AM, YU ZHANG <yu.zhang at oracle.com> wrote:

>  Very interesting post.  Like someone mentioned in the comments, with
> -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled, CMS can clean
> classes in PermGen with minor GC.  But G1 can only unload class during full
> gc.  Full GC in G1 is slow as it is single threaded.
>
>  Thanks,
> Jenny
>
> On 1/3/2014 7:47 AM, Jose Otavio Carlomagno Filho wrote:
>
> We recently switched to G1 in our application and started experiencing
> this type of behaviour too. Turns out G1 was not causing the problem, it
> was only exposing it to us.
>
>  Our application would generate a large number of proxy classes and that
> would cause the Perm Gen to fill up until a full GC was performed by G1.
> When using ParallelOldGC, this would not happen because full GCs would be
> executed much more frequently (when the old gen was full), which prevented
> the perm gen from filling up.
>
>  You can find more info about our problem and our analysis here:
> http://stackoverflow.com/questions/20274317/g1-garbage-collector-perm-gen-fills-up-indefinitely-until-a-full-gc-is-performe
>
>  I recommend you use a profiling too to investigate the root cause of
> your Perm Gen getting filled up. There's a chance it is a leak, but as I
> said, in our case, it was our own application's fault and G1 exposed the
> problem to us.
>
>  Regards,
> Jose
>
>
> On Fri, Jan 3, 2014 at 1:33 PM, Wolfgang Pedot <wolfgang.pedot at finkzeit.at
> > wrote:
>
>> Hi,
>>
>> I am using G1 on 7u45 for an application-server which has a "healthy"
>> permGen churn because it generates a lot of short-lived dynamic classes
>> (JavaScript). Currently permGen is sized at a little over 1GB and
>> depending on usage there can be up to 2 full GCs per day (usually only
>> 1). I have not noticed an increased permGen usage with G1 (increased
>> size just before switching to G1) but I have noticed something odd about
>> the permGen-usage after a collect. The class-count will always fall back
>> to the same level which is currently 65k but the permGen usage after
>> collect can either be ~0.8GB or ~0.55GB. There are always 3 collects
>> resulting in 0.8GB followed by one scoring 0.55GB so there seems to be
>> some kind of "rythm" going on. The full GCs are always triggered by
>> permGen getting full and the loaded class count goes significantly
>> higher after a 0.55GB collect (165k vs 125k) so I guess some classes
>> just get unloaded later...
>>
>> I can not tell if this behaviour is due to G1 or some other factor in
>> this application but I do know that I have no leak because the
>> after-collect values are fairly stable over weeks.
>>
>> So I have not experienced this but am sharing anyway ;)
>>
>> happy new year
>> Wolfgang
>>
>> Am 03.01.2014 10:12, schrieb Srinivas Ramakrishna:
>>  > I haven't narrowed it down sufficiently yet, but has anyone noticed if
>> > G1 causes a higher perm gen footprint or, worse, a perm gen leak
>> perhaps?
>> > I do realize that G1 does not today (as of 7u40 at least) collect the
>> > perm gen concurrently, rather deferring its collection to a stop-world
>> full
>> > gc. However, it has just come to my attention that despite full
>> > stop-world gc's (on account of the perm gen getting full), G1 still uses
>> > more perm gen
>> > space (in some instacnes substantially more) than ParallelOldGC even
>> > after the full stop-world gc's, in some of our experiments. (PS: Also
>> > noticed
>> > that the default gc logging for G1 does not print the perm gen usage at
>> > full gc, unlike other collectors; looks like an oversight in logging
>> > perhaps one
>> > that has been fixed recently; i was on 7u40 i think.)
>> >
>> > While I need to collect more data using non-ParallelOld, non-G1
>> > collectors (escpeially CMS) to see how things look and to get closer to
>> > the root
>> > cause, I wondered if anyone else had come across a similar issue and to
>> > check if this is a known issue.
>> >
>> > I'll post more details after gathering more data, but in case anyone has
>> > experienced this, please do share.
>> >
>> > thank you in advance, and Happy New Year!
>> > -- ramki
>> >
>> >
>>  > _______________________________________________
>> > hotspot-gc-use mailing list
>> > hotspot-gc-use at openjdk.java.net
>> > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>> >
>>
>> _______________________________________________
>> hotspot-gc-use mailing list
>> hotspot-gc-use at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>>
>
>
>
> _______________________________________________
> hotspot-gc-use mailing listhotspot-gc-use at openjdk.java.nethttp://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>
>
>
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20140103/75e83946/attachment-0001.html 