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

[YU ZHANG]

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 <mailto: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
>     <mailto: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
>     <mailto: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

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