G1: higher perm gen footprint or a possible perm gen leak?
Bengt Rutisson
bengt.rutisson at oracle.com
Tue Jan 7 01:21:15 PST 2014
Hi all,
First just a note about the missing PermGen data in the full GC output.
That has been fixed for JDK 8 where (there the metadata information is
printed instead of course) but I don't think it has been backported to 7u.
G1: Output for full GCs with +PrintGCDetails should contain perm
gen/meta data size change info
https://bugs.openjdk.java.net/browse/JDK-8010738
On 2014-01-03 22:52, Thomas Schatzl 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.
Yes, this would be my first guess too. We have seen differences between
ParallelGC and G1 in the soft reference handling. I think this is mostly
due to the different way they estimate the used and free space on the
heap since the actual calculation based on that data is then the same
for all collectors. On the other hand, as I recall, we saw the opposite
behavior. That G1 is more aggressive about cleaning soft references than
ParallelGC.
Maybe playing around a bit with -XX:SoftRefLRUPolicyMSPerMB can help?
Bengt
>
>> 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.
>
> Thomas
>
>
>
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
More information about the hotspot-gc-use
mailing list